8000 deprecate isscalar, change behavior? · Issue #19690 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

deprecate isscalar, change behavior? #19690

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.

Sign up for GitHub

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

Jump to bottom
Open
nschloe opened this issue Aug 17, 2021 · 5 comments
Open

deprecate isscalar, change behavior? #19690

nschloe opened this issue Aug 17, 2021 · 5 comments

Comments

@nschloe
Copy link
Contributor
nschloe commented Aug 17, 2021

Right now, np.isscalar returns True iff the input is a Python scalar:

import numpy as np

np.isscalar(3.14)              # True
np.isscalar(np.array(3.14))    # False
np.isscalar(np.array([3.14]))  # False

However, np.arrays with ndim == 0 smell, taste, and behave like Python scalars in almost all situations, so you almost always want to admit ndim-0 arrays when writing if np.isscalar(a): .... Unfortunately, downstream uses isscalar far more often (e.g. scipy: 61 isscalar, 9 ndim). This begs the question if np.isscalar should be deprecated or its behavior changed to

def isscalar(x):
    return np.ndim(x) == 0
@nschloe nschloe mentioned this issue Aug 17, 2021
Merged
@eric-wieser
Copy link
Member

#11882 was the first step towards a possible deprecation, which documented the reasons to avoid isscalar.

@pankaj-cipher
Copy link
8000

Talking about the above situation depreciating np.isscalar() . I would rather suggest deprecating 0D-arrays because 0D-arrays are no more arrays , they are scalars and obviously a array(vector) couldn't be a scalar . So, basically rather changing the definition for np.isscalar(), it should be changed for np.array(scalar).

@nschloe
Copy link
Contributor Author
nschloe commented Aug 18, 2021

0D-arrays are no more arrays , they are scalars

I agree! I wouldn't vote for their deprecation though because there are many situations where you want scalars to be treated just like arrays, e.g., when evaluating functions ("vectorization").

@eric-wieser
Copy link
Member
eric-wieser commented Aug 18, 2021 •
edited
Loading

I don't think changing the behavior of isscalarthis late in the game is sensible. Even numpy itself depends on the weirdness of its behavior (it uses it to mean "can I modify this safely in place with +=" in some instances); so I would expect many downstream breakages. Yes, we should have defined it that way in the first place, but given we didn't, and that np.ndim(x) == 0 is only one character longer, it's not worth the breakage.

I'd argue that isscalar isn't even a better name; there's no clear definition of what counts as a scalar, so users read it as whichever meaning they think they want at the moment and not the one it actually implements.

0D arrays have their place, and I don't think for a moment would be a good idea to remove

@seberg
Copy link
Member
seberg commented Aug 18, 2021 •
edited
Loading

0D arrays have their place, and I don't think for a moment would be a good idea to remove

It is a common argument to get rid of scalars, but never I have not heard getting rid of 0-D arrays :).

What is a "scalar" in NumPy depends, there are at least three definitions:

  1. A scalar is equivalent to np.asarray(x, dtype=dtype).ndim == 0
  2. Same as 1., but do not accept anything deemed array-like
  3. Same as 2., but only accept "recognized" scalars (i.e. an arbitrary object is not a scalar, we never probe whether it is an array-like). An example would also be class o: def __float__(self): 1., which can be stored in a float array, but is not recognized. In this definition even a subclass of a float may be rejected.

(I guess 2. and 3. could also be solved with a three-way function that returns scalar, array-like, unknown, and possibly array-like-scalar)

And note that the dtype=dtype actually has an effect. As an extreme case dtype=object means that anything is technically a scalar (even a 0-D array). A tuple is a scalar if the input is a structured dtype. A vector object could be an array-like unless the dtype=vector.

We should not change isscalar to mean ndim == 0 IMO. We might be able to tweak it to be better defined (I am not actually sure what it roughly does currently) with respect to 2. or 3.
If we do not need 2. or 3., then I would agree that deprecating is probably just as well. Even if we need 2. or 3. it seems likely better to just add something better defined and deprecate it anyway (rather than trying to fix isscalar).

@rkern rkern mentioned this issue Apr 13, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@seberg @nschloe @eric-wieser @pankaj-cipher
0