On Tue, 2023-05-16 at 11:46 -0400, Warren Weckesser wrote:
> On 4/21/23, Sebastian Berg <sebast...@sipsolutions.net> wrote:
> > 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?
> >
>
> Sorry for the late reply; the recent comment in
> https://github.com/numpy/numpy/issues/23400 reminded me of this. As
> noted in the link in the recent comment in that issue, handling of
> nonscalar inputs of the numpy scalar types was also briefly discussed
> in the mailing list three years ago:
> https://mail.python.org/pipermail/numpy-discussion/2020-April/080566.html
>
> I don't have any concrete ideas other than outright deprecating the
> handling of anything that is not a scalar, but that might be too
> disruptive.
>
Not sure it is very disruptive, but I don't have a lot of appetite for
a full deprecation myself right now.
Was more hoping to nail down the best (now) solution that isn't a
deprecation :).
- Sebastian
> 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: 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: arch...@mail-archive.com
