Renaming findn and findnz?

[andreasnoack]

As discussed in #24724 these behave slightly different from other functions so it might be worth renaming them as part of the general work described in https://github.com/JuliaLang/Juleps/blob/master/Find.md

[nalimilan]

As noted at #24724, findn wouldn't be needed if find returned CartesianIndexes for matrices, as #24774 does. findn(x) could then be find(!iszero, x), with a specialized sparse matrix method for efficiency.

findnz could be renamed to stored or filled, which would have the advantage of moving away from the too restrictive "zero"/"nonzero" terminology. nnz should also be renamed at the same time.

[Sacha0]

findnz could be renamed to stored or filled, which would have the advantage of moving away from the too restrictive "zero"/"nonzero" terminology. nnz should also be renamed at the same time.

👍 Revising the names of sparse array type fields and associated functions to better reflect present semantics (and possibly enable SparseVector-SparseMatrixCSC unification) is on my list of hypothetical post-1.0 projects, so this direction sounds great on this end :).

[nalimilan]

@Sacha0 What concrete changes do you think should happen before 1.0 here? Renaming findnz to stored and nnz to something else?

[StefanKarpinski]

How about Sparse.stored and Sparse.nstored?

[Sacha0]

@Sacha0 What concrete changes do you think should happen before 1.0 here? Renaming findnz to stored and nnz to something else?

The findn(x) -> find(!iszero, x) change sounds lovely and realistic for 1.0. Is that change pending or has it already gone through?

findnz(A) generates a COO (coordinate) representation of A from its nonzeros, independent of what A stores. A name reflecting that behavior seems best? (stored does not quite capture that behavior, and perhaps should be reserved for other uses in a future overhaul of sparse arrays.)

nnz -> numstored is what I had in mind for a future overhaul; I prefer numstored's clarity to nstored :). Best!

[nalimilan]

The findn(x) -> find(!iszero, x) change sounds lovely and realistic for 1.0. Is that change pending or has it already gone through?

It's still pending, blocked by #24774. I think we should merge that PR anyway and take care of performance later.

findnz(A) generates a COO (coordinate) representation of A from its nonzeros, independent of what A stores. A name reflecting that behavior seems best? (stored does not quite capture that behavior, and perhaps should be reserved for other uses in a future overhaul of sparse arrays.)

OK. Do we really need both findn (or it's replacement) and findnz? I'm not very clear about their differences.

nnz -> numstored is what I had in mind for a future overhaul; I prefer numstored's clarity to nstored :).

I prefer nstored, since "num" evokes "numeric" and because we already have e.g. nfield. But that's not a big deal.

To be honest, I wouldn't mind some help for issues which are not blocked by progress on my other PRs. :-)

[StefanKarpinski]

It's still pending, blocked by #24724.

That's merged already though...

[Sacha0]

OK. Do we really need both findn (or it's replacement) and findnz? I'm not very clear about their differences.

Insofar as I am concerned, no. I can't remember the last time I used findnz; usually a better way to achieve whatever you want to achieve with it exists :).

[nalimilan]

That's merged already though...

Woops, sorry, I meant #24774.