On Thu, 2023-04-20 at 20:17 +0200, Sebastian Berg wrote:
> On Thu, 2023-04-20 at 13:59 -0400, Warren Weckesser wrote:
> > On 4/20/23, Sebastian Berg <sebast...@sipsolutions.net> wrote:
> > > Hi all,
> > >
> > >
>
> <snip>
>
> >
> > In [64]: np.float64(np.array([0.0]))
> > <ipython-input-64-0f0309f2cf0c>:1: DeprecationWarning: Conversion
> > of
> > an array with ndim > 0 to a scalar is deprecated, and will error in
> > future. Ensure you extract a single element from your array before
> > performing this operation. (Deprecated NumPy 1.25.)
> > np.float64(np.array([0.0]))
> > Out[64]: 0.0
> >
> > In [65]: np.float64(np.array([0.0, 0.0]))
> > Out[65]: array([0., 0.])
Do you have any thoughts on how to make progress Warren?
Had a bit of a look at it. You are probably aware that this is because
for float, str, and bytes (our subclasses of them), we have
(approximately):
def __new__(cls, *args, **kwargs):
try:
super().__new__(*args, **kwargs)
except:
if len(args) != 1 or kwargs != {}:
raise
return np.asarray(args[0])[()] # scalar if 0-D
For float64, I am tempted to just remove the super() path entirely and
put in a fast-path for simple scalar object (like python `int`,
`float`, `bool`, `str`) to avoid the full `np.asarray()` call.
For unicode/bytes its a bit of a mess though? I suspect for them the
`array` path is currently just useless in practice, because even arrays
are interpreted as scalars here.
The best path might be even to just deprecate array input entirely for
them? Even then you have at least one case that is tricky:
np.bytes_(5)
returns an empty string (since we strip zeros) but if we would do the
same as `np.asarray(5, dtype=np.bytes_)[()]` we would get a different
result.
(And raising on a non 0-D array doesn't help there.)
Maybe the right way is to go as far and check if both paths match for
non-trivial bytes?!
- Sebastian
> >
>
> Hmmmpf, that would be a good follow-up to fix. In theory a
> FutureWarning I guess (returning the array), but in practice, I think
> we should just give the correct array result.
>
> (I don't love returning arrays from scalar constructors, but that is
> another thing and not for now.)
>
> - Sebsatian
>
>
> > ```
> >
> > In 1.24.2, `np.float64(np.array([0.0])` returns the the scalar 0.0.
> >
> > If passing arrays to `np.float64()` is intentionally supported, it
> > seems it would be more consistent for `np.float64(np.array([0.0]))`
> > to
> > return `np.array([0.0])`. That is how the other numpy types work
> > (e.g. `np.complex128`, `np.int64`, etc.). But I'm not sure if there
> > is
> > a deprecation/update path that would get us there.
> >
> > Warren
> >
> > >
> > > _______________________________________________
> > > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > > To unsubscribe send an email to numpy-discussion-le...@python.org
> > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > > Member address: warren.weckes...@gmail.com
> > >
> > _______________________________________________
> > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > To unsubscribe send an email to numpy-discussion-le...@python.org
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: sebast...@sipsolutions.net
> >
>
>
> _______________________________________________
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: sebast...@sipsolutions.net
_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
