scalartype function?

[ettersi]

Consider a collection c of numeric objects and assume I want to retrieve the underlying scalar type. The prototypical example is Vector{T <: Number}, for which the desired type can be obtained by calling eltype(c). The purpose of eltype is to return the type obtained when iterating the collection, however, and it is just a lucky coincidence that for Vector{T} the scalar type and the element type agree. In many other cases, this is no longer true.

• In a molecular dynamics simulation, we might store the particle coordinates as a collection of coordinates, so eltype of that collection is Vector{T} while scalartype should be T.
• Iterating a sparse matrix could return (i,j,v) triplets of the non-zero elements (that's not what the Julia SparseMatrixCSC class does). Then eltype would be (Int,Int,T) while scalartype should be T.
• The tensor network approach stores a huge high-dimensional array as a collection of many low-dimensional arrays. In this case, eltype would be Array{T,N} while scalartype would be T.

I recently ended up implementing a new scalartype function in every module for which this problem occurs, but obviously that might soon lead to name collisions. Would it make sense to provide such a function in Julia Base such that every library only adds new methods for its types? The coding effort for this change should be absolutely minimal:

• Add a function scalartype(x) = scalartype(typeof(x)) somewhere.
• Add methods for a few types in Julia Base, e.g. Array, Factorization, SparseMatrixCSC.

The downside of the proposed feature is that it adds a new function and thus additional complexity to the ecosystem. I can't think of a better solution to this problem, however, and I highly assume I am not the only one who has ever run into this issue.

[eschnett]

Do I understand correctly that your scalartype is a fixed point for eltype? That is, one implementation of scalartype would be to call eltype until the result doesn't change any more?

If so, there's a related function that would make sense as well, namely a fixed point for collect, with typeof(scalarcollect(x)) == scalartype(x).

[ettersi]

In the first and third example above, your implementation of scalartype would work, but not in the second case. I guess while many cases could be handled in the way you propose, it seems a bit of a stretch to make this the default behaviour.

Do I understand correctly that in the MD example, the scalarcollect function you propose should merge all the n coordinate vectors of length d into one long vector of length n*d? I see that such a function might have its applications e.g. when you do implicit time-stepping and need to solve an LSE in all n*d coordinates, but the scope seems to be more limited in my eyes.

[ettersi]

Oops, didn't mean to close. Sorry for the spam!

[KristofferC]

+1 for something like this.

For example when doing automatic differentiation on a function that normally takes a v::Vector{T} you will get your function called with a v::Vector{ADNumber{T}} but sometimes it is still desirable to access the T:. RIght now I am just doing eltype(eltype(..)).

[ettersi]

Just ran into the need for scalartype again, so I thought I'd give this another bump. This time, the use case is an interpolation function which can interpolate both scalars and vectors.
I can't be the only one with this issue, can I?