Just checked 1.12.0 as well and does not seem to be an error there either.

sparse.csr_array(int()) is equivalent to sparse.csr_array(np.array(0)). So I suppose the question is whether that should be allowed.

We don't support 0-D sparse arrays. So I think this slipped through our shape checking changes.
That will still not make it conform to array_api, but it will be a different error message.

I'm not sure what a sparse version of a 0-D array would look like. Probably raising is the right thing to do even if that breaks array_api. @ilan-gold what do you think should be returned in this case?

@dschult Let me do some fiddling and inspection. This isn't even in one of the tests for the array api, it's just in the lead up to starting the tests. So maybe it's not even in there (although I somewhat doubt this).

We don't support 0-D sparse arrays.

Is there a design document or the like I could look at as a reference for this sort of thing?

Indexing a 2-D CSR array yields a numpy scalar:

>>> csr_2d[1, 1]
np.float64(1.0)

That is the same behavior as numpy, and given that numpy scalars duck type as 0-D arrays, this is okay. So there shouldn't be an urgent need for 0-D sparse arrays I'd think.

That said, if 1-D sparse arrays are a thing, I don't see why 0-D sparse arrays shouldn't be a thing also. It's probably more a "is it worth it" question.

In terms of " is it worth it" (since we will be getting 1D sparse arrays from what I understand), I would think maybe yes? Beyond the goal of matching numpy's behavior (which is an array with shape ()), this behavior is "officially" tested in the array api. However, I don't see anything officially in the spec. Could you point me to it if it is there?

I think the overriding factor should be the array api's demands and then secondarily can think about numpy.

However, I don't see anything officially in the spec. Could you point me to it if it is there?

From https://data-apis.org/array-api/draft/API_specification/array_object.html: "Furthermore, a conforming implementation of the array API standard must support, at minimum, array objects of rank (i.e., number of dimensions) 0, 1, 2, 3, and 4 and must explicitly document their maximum supported rank N. ... Conforming implementations must support zero-dimensional arrays."

It is pretty weird indeed to return numpy scalars (i.e., a more-or-less 0-D array from another library) for a standard operation like indexing a 1-D or 2-D array.

Thanks! So it seems we do indeed need this behavior to not error for array api to work then. And more generally, beyond being able to construct these arrays as the issue here specifies, we need the return type of scipy sparse arrays then to also be of this 0-d type.

This is somewhat related to #19919 as well. The array api test suite actually provides a nice barrage of tests by which we could try to standardize some of this behavior. I will do some more digging to formalize a list or at least some more concrete points of what exactly is needed/missing.

But that is separate from this issue, which I think is focused on construction, not return types.

So it seems we do indeed need this behavior to not error for array api to work then

Note the discussion in gh-18915, it seems unlikely that we'll reach a point where scipy.sparse arrays will "work" with the array API standard. (Maybe you just mean 'work, as far as we can with what is in scope')

@lucascolley I agree, but it just seemed that this case was special given that covering it is apparently needed just to get the tests to run at all. Otherwise I don't think I would have posted it.

One thing I can see as a result of thinking about this would be some level of customization for hypothesis tests in the array api test suite. This would allow us to pass tests we want to, while being clear about what we don't support. I am not really sure it makes sense to have some sort of testing suite where some things pass and others error, which we then have to track by hand somehow. I imagine we will not be the only ones with this issue. Although, I guess trakcing by hand isn't the worst thing, although it would not let us customize to only do 2D tests for example. So we might want __getitem__ to pass for 2D but not 3D.

One thing I can see as a result of thinking about this would be some level of customization for hypothesis tests in the array api test suite. This would allow us to pass tests we want to, while being clear about what we don't support.

Have you seen https://github.com/numpy/numpy/blob/main/tools/ci/array-api-skips.txt?

Oh very cool @lucascolley thanks! I had not!

Additional tests (and maybe tests of what we don't support) would naturally go into the scipy.sparse module scipy/sparse/tests/test_array_api.py

NumPy just installs array-api-tests in a CI job and passes in the list of skips: https://github.com/numpy/numpy/blob/18c13458d544d9b935b63e7b495a346ec14f5468/.github/workflows/linux.yml#L212-L249

I'm thinking about what a 0D sparse array would look like. I think we would just want to make numpy ndarray 0D arrays be the sparse array 0D arrays. They aren't identified as scipy.sparse in any way. But is that even needed? I guess what I mean is -- to support the array api we can combine array types with other libraries, right? (There is already at least one place where we return a dense nd array for n>2. I can't quite recall, but I think it is after multiplying a sparse array by a nd dense array.)

@dschult After our discussion I did some work on this. I am not sure I am actually that comfortable just sort of saying "np arrays are 0d arrays." I have a branch for this and I'll make a PR but given the low turnout at the last WG, I'll just keep my branch (which goes sparse.csr_array(int()) -> 1x1 sparse array) and then we can discuss at the next one. I do think np.array would be easiest but I am not sure it makes programming sense (i.e., declare a class and then just get a completely unrelated one).

I guess you mean: you're not comfortable saying "np scalars are 0d arrays".

The option of: sparse.csr_array(int()) -> 1x1 sparse array matches what sparse_matrix does: treating 0d input as 2d by default. But I thought that the array-api says that array libraries should provide a 0d option.

Can you show us the disadvantages of using 0d numpy arrays? You mention that it doesn't make sense to "declare a class and then just get a completely unrelated one" -- but these are certainly not completely unrelated. And that standard doesn't seem to fit with the array-api ethos. I'm not saying we really should use numpy 0d for scipy sparse. I'm trying to figure out what the disadvantages and advantages of that approach are in terms of the array-api, and in terms of users not having to change their code much when switching libraries (which I think of as the driver of the array-api approach).

But I thought that the array-api says that array libraries should provide a 0d option.

I think we are not going to support everything in the array api anyway but since this is needed to get tests running we need to return something that has a dtype attribute.

For advantages/disadvantages, I am not sure there's really a disadvantage of using a numpy array besides the semantics - they are not completely unrelated, but returning a different class from a different package from the constructor is just kind of strange to me. It is true that we'll need to "support" numpy arrays as a returned class anyway (as far as I can tell) for mixed ops that might produce a dense array.

It seems to me that a 1x1 sparse array would be nice with the disadvantage being that it might make sense to implement 0d sparse arrays if/when 1d arrays are merged, in which case this doesn't matter so much. But I don't think that's a good idea. As @ivirshup pointed out, despite the 1d array work, these are fundamentally 2d classes....So I'm still in favor of 1x1 sparse array.

Decision: throw an error uniformly across all sparse array classes.