New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: csr_array(int())
errors
#20128
Comments
Just checked |
|
We don't support 0-D sparse arrays. So I think this slipped through our shape checking changes. 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).
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 I think the overriding factor should be the array api's demands and then secondarily can think about |
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 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. |
Note the discussion in gh-18915, it seems unlikely that we'll reach a point where |
@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 |
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 |
NumPy just installs |
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 |
I guess you mean: you're not comfortable saying "np scalars are 0d arrays". The option of: 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). |
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 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. |
Describe your issue.
It seems like the described behavior does no work while
np.array(int())
does seem to work. This comes from the array api test suite setup, so presumably it should work and indeed does forcsr_matrix
. I think the error is recent (or onmain
) because it does not error in1.11.4
. I know there has been a lot of work around 1d so sorry if this is expected! Happy to fix if it's a real bug!Reproducing Code Example
Error message
SciPy/NumPy/Python version and system information
The text was updated successfully, but these errors were encountered: