[Numpy-discussion] deprecating float(x) for ndim > 0

[Nico Schlömer]

Hi everyone,

This is seeking input on PR [1] which I've worked on with @eric-wieser
and @seberg. It deprecates
```
float(x)
```
if `x` is an array of ndim > 0. (It works with all arrays of size 1
right now.) This aligns the behavior of float() on ndarrays with
float() on lists which already fails today. It also deprecates the
implicit conversion to float in assignment expressions like
```
a = np.array([1, 2, 3])
a[0] = [5]  # deprecated, should be a[0] = 5
```
In general, the PR makes numpy a tad bit stricter on how it treats
scalars vs. single-item arrays.

The change also prevents the #1 wrong usage of float(), namely for
extracting the scalar value from an array. One should rather use
`x[0]` or `x.item()` to that which doesn't convert the value to a
Python float.

To estimate the impact of the PR, I looked at major numpy dependents
like matplotlib, scipy, pandas etc., and of course numpy itself.
Except scipy, all projects were virtually clean to start with. Scipy
needed some changes for all tests to pass without warning, and all of
the changes were improvements. In particular, the deprecation
motivates users to use actual scalars when scalars are needed, e.g.,
in the case of scipy, as the return value of a goal functional.

It'd be great if you could try the branch against your own project and
let us know (here or in the PR) about and problems that you might
have.

Thanks!
Nico

[1] https://github.com/numpy/numpy/pull/10615
[2] https://github.com/numpy/numpy/issues/10404
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[george trojan]

Responding to the post by nico.schloe...@gmail.com (I subscribe to the
digest).

I just wrote the following code:

twb = scipy.optimize.fsolve(phi, tdb, args=(tdb, p, w, hd_tdb, hg_tdb),
xtol=1e-8)
tdb, p, w, hd_tdb, hg_tdb
twb.shape
print("wet-bulb temperature {:.5f} [deg K]".format(float(twb)))

The output is

(313.15, 101325.0, 0.009200033532084696, 40182.343155896095, 2573510.322137241)

(1,)

wet-bulb temperature 295.17583 [deg K]

All arguments are floats, the function phi returns float as well. I did
expect the output to be float. Instead I got a 1d array. Were my
expectations wrong? The print statement would stop working after
deprecation.

George
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[Stephan Hoyer]

On Wed, Sep 15, 2021 at 5:18 AM Nico Schlömer 
wrote:

> Hi everyone,
>
> This is seeking input on PR [1] which I've worked on with @eric-wieser
> and @seberg. It deprecates
> ```
> float(x)
> ```
> if `x` is an array of ndim > 0. (It works with all arrays of size 1
> right now.) This aligns the behavior of float() on ndarrays with
> float() on lists which already fails today. It also deprecates the
> implicit conversion to float in assignment expressions like
> ```
> a = np.array([1, 2, 3])
> a[0] = [5]  # deprecated, should be a[0] = 5
> ```
> In general, the PR makes numpy a tad bit stricter on how it treats
> scalars vs. single-item arrays.
>
> The change also prevents the #1 wrong usage of float(), namely for
> extracting the scalar value from an array. One should rather use
> `x[0]` or `x.item()` to that which doesn't convert the value to a
> Python float.
>

Hi Nico,

I think this is a great idea! Another good alternative to mention is
explicitly calling .squeeze() first, to remove all size 1 dimensions.

Cheers,
Stephan


> To estimate the impact of the PR, I looked at major numpy dependents
> like matplotlib, scipy, pandas etc., and of course numpy itself.
> Except scipy, all projects were virtually clean to start with. Scipy
> needed some changes for all tests to pass without warning, and all of
> the changes were improvements. In particular, the deprecation
> motivates users to use actual scalars when scalars are needed, e.g.,
> in the case of scipy, as the return value of a goal functional.
>
> It'd be great if you could try the branch against your own project and
> let us know (here or in the PR) about and problems that you might
> have.
>
> Thanks!
> Nico
>
> [1] https://github.com/numpy/numpy/pull/10615
> [2] https://github.com/numpy/numpy/issues/10404
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[Hameer Abbasi]

Hello Nico,

Any step in the direction of consistency and type safety is a good one to me. 
I’m +1 on this change.

Best regards,
Hameer Abbasi

> Am 15.09.2021 um 14:18 schrieb Nico Schlömer :
> 
> Hi everyone,
> 
> This is seeking input on PR [1] which I've worked on with @eric-wieser
> and @seberg. It deprecates
> ```
> float(x)
> ```
> if `x` is an array of ndim > 0. (It works with all arrays of size 1
> right now.) This aligns the behavior of float() on ndarrays with
> float() on lists which already fails today. It also deprecates the
> implicit conversion to float in assignment expressions like
> ```
> a = np.array([1, 2, 3])
> a[0] = [5]  # deprecated, should be a[0] = 5
> ```
> In general, the PR makes numpy a tad bit stricter on how it treats
> scalars vs. single-item arrays.
> 
> The change also prevents the #1 wrong usage of float(), namely for
> extracting the scalar value from an array. One should rather use
> `x[0]` or `x.item()` to that which doesn't convert the value to a
> Python float.
> 
> To estimate the impact of the PR, I looked at major numpy dependents
> like matplotlib, scipy, pandas etc., and of course numpy itself.
> Except scipy, all projects were virtually clean to start with. Scipy
> needed some changes for all tests to pass without warning, and all of
> the changes were improvements. In particular, the deprecation
> motivates users to use actual scalars when scalars are needed, e.g.,
> in the case of scipy, as the return value of a goal functional.
> 
> It'd be great if you could try the branch against your own project and
> let us know (here or in the PR) about and problems that you might
> have.
> 
> Thanks!
> Nico
> 
> [1] https://github.com/numpy/numpy/pull/10615
> [2] https://github.com/numpy/numpy/issues/10404
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[Sebastian Berg]

On Wed, 2021-09-15 at 17:25 +, george trojan wrote:
> Responding to the post by nico.schloe...@gmail.com (I subscribe to
> the
> digest).
> 
> I just wrote the following code:
> 
> twb = scipy.optimize.fsolve(phi, tdb, args=(tdb, p, w, hd_tdb,
> hg_tdb),
> xtol=1e-8)
> tdb, p, w, hd_tdb, hg_tdb
> twb.shape
> print("wet-bulb temperature {:.5f} [deg K]".format(float(twb)))
> 
> The output is
> 
> (313.15, 101325.0, 0.009200033532084696, 40182.343155896095,
> 2573510.322137241)
> 
> (1,)
> 
> wet-bulb temperature 295.17583 [deg K]
> 
> All arguments are floats, the function phi returns float as well. I
> did
> expect the output to be float. Instead I got a 1d array. Were my
> expectations wrong? The print statement would stop working after
> deprecation.

Yes, this is exactly the type of issue that we are interested in this
discussion.  I don't know whether this one could be exactly one of
those things that have been fixed in SciPy.  But right now the code
ends up just "flattening" your 0-D array:

 x0 = asarray(x0).flatten()

Which may be unexpected (or maybe it should be expected?).  The
question is how common it is.  If it is rare enough, I would like to
get away with it personally.  But if it is too annoying in in the real
word...

One thing we could try to do is improve the error message (it is pretty
good already I think).  We could go as far as including instructions
depending on whether the array is 1-D or N-D and even link to a website
for more pointers.

Cheers,

Sebastian


> 
> George
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[Andrew Nelson]

On Thu, 16 Sep 2021, 03:25 george trojan,  wrote:

>
> I just wrote the following code:
>
> twb = scipy.optimize.fsolve(phi, tdb, args=(tdb, p, w, hd_tdb, hg_tdb),
> xtol=1e-8)
> tdb, p, w, hd_tdb, hg_tdb
> twb.shape
> print("wet-bulb temperature {:.5f} [deg K]".format(float(twb)))
>
> The output is
>
> (313.15, 101325.0, 0.009200033532084696, 40182.343155896095, 
> 2573510.322137241)
>
> (1,)
>
> wet-bulb temperature 295.17583 [deg K]
>
> All arguments are floats, the function phi returns float as well. I did
> expect the output to be float. Instead I got a 1d array. Were my
> expectations wrong?
>

In the return section for fsolve the documentation states that the return
value, `x`, is an `ndarray`.

>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[Aaron Meurer]

Presumably this also changes int(), bool(), and complex() in the same way.

The array API standard (and numpy.array_api) only requires float(),
bool(), and int() (and soon complex()) for dimension 0 arrays (the
standard does not have scalars), in part because of this NumPy issue
https://data-apis.org/array-api/latest/API_specification/array_object.html#float-self.

On Wed, Sep 15, 2021 at 6:18 AM Nico Schlömer  wrote:
>
> Hi everyone,
>
> This is seeking input on PR [1] which I've worked on with @eric-wieser
> and @seberg. It deprecates
> ```
> float(x)
> ```
> if `x` is an array of ndim > 0. (It works with all arrays of size 1
> right now.) This aligns the behavior of float() on ndarrays with
> float() on lists which already fails today. It also deprecates the
> implicit conversion to float in assignment expressions like
> ```
> a = np.array([1, 2, 3])
> a[0] = [5]  # deprecated, should be a[0] = 5

This already gives a ValueError in NumPy 1.21.1. Do you mean a[0] =
np.array([5]) is deprecated?

I was playing with this though and was a little surprised to find
NumPy allows things like this:

>>> a = np.array([1, 2, 3])
>>> a[:] = np.array([[[5, 6, 7]]])
>>> a
array([5, 6, 7])

Array assignment allows some sort of reverse broadcasting? Given this
behavior, it seems to me that a[0] = np.array([5]) actually should
work. Or is the idea that this entire behavior would be deprecated?

Aaron Meurer

> ```
> In general, the PR makes numpy a tad bit stricter on how it treats
> scalars vs. single-item arrays.
>
> The change also prevents the #1 wrong usage of float(), namely for
> extracting the scalar value from an array. One should rather use
> `x[0]` or `x.item()` to that which doesn't convert the value to a
> Python float.
>
> To estimate the impact of the PR, I looked at major numpy dependents
> like matplotlib, scipy, pandas etc., and of course numpy itself.
> Except scipy, all projects were virtually clean to start with. Scipy
> needed some changes for all tests to pass without warning, and all of
> the changes were improvements. In particular, the deprecation
> motivates users to use actual scalars when scalars are needed, e.g.,
> in the case of scipy, as the return value of a goal functional.
>
> It'd be great if you could try the branch against your own project and
> let us know (here or in the PR) about and problems that you might
> have.
>
> Thanks!
> Nico
>
> [1] https://github.com/numpy/numpy/pull/10615
> [2] https://github.com/numpy/numpy/issues/10404
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] graphic design contribution to NumPy

[Inessa Pawson]

Hi, Vasiliy!
It would be great if the infographic embraces the flat design principles
and echoes the style of other graphic elements of the website.

Let’s continue this conversation on GitHub, in the comments for the issue
#435 .

On Tue, Sep 14, 2021 at 12:00 PM 
wrote:

> Send NumPy-Discussion mailing list submissions to
> numpy-discussion@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/numpy-discussion
> or, via email, send a message with subject or body 'help' to
> numpy-discussion-requ...@python.org
>
> You can reach the person managing the list at
> numpy-discussion-ow...@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NumPy-Discussion digest..."
> Today's Topics:
>
>1. graphic design contribution (Holam Gadol)
>
>
>
> -- Forwarded message --
> From: Holam Gadol 
> To: Discussion of Numerical Python 
> Cc:
> Bcc:
> Date: Mon, 13 Sep 2021 23:11:07 +0300
> Subject: [Numpy-discussion] graphic design contribution
> Thank you for replying, Inessa.
>
> Refining infographics from the issue #435
>  looks interesting.
>
> Do you have a particular style for them? I saw the icons were redrawn in
> material design. Should infographics follow the same style?
>
> Best wishes,
> Vasiliy
>
>
> пн, 13 сент. 2021 г. в 06:11, Inessa Pawson :
>
>> Thank you for offering your help, Holam!
>> We have quite a few options for you. If you’d like to help us improve
>> numpy.org, this is the latest discussion on this topic:
>> https://github.com/numpy/numpy.org/issues/342 . We could also apply your
>> graphic design skills to enhance our documentation and educational
>> materials.
>> Let me know what you’d like to take on, and I will send you more info
>> about it.
>>
>> On Sat, Sep 11, 2021 at 12:04 PM 
>> wrote:
>>
>>> Send NumPy-Discussion mailing list submissions to
>>> numpy-discussion@python.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>> or, via email, send a message with subject or body 'help' to
>>> numpy-discussion-requ...@python.org
>>>
>>> You can reach the person managing the list at
>>> numpy-discussion-ow...@python.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of NumPy-Discussion digest..."
>>> Today's Topics:
>>>
>>>1. graphic design contribution (Holam Gadol)
>>>
>>>
>>>
>>> -- Forwarded message --
>>> From: Holam Gadol 
>>> To: numpy-discussion@python.org
>>> Cc:
>>> Bcc:
>>> Date: Sat, 11 Sep 2021 16:05:43 +0300
>>> Subject: [Numpy-discussion] graphic design contribution
>>> Greetings to everyone!
>>>
>>> I`de like to help the numpy project with graphic design.
>>>
>>> What are the first steps to start with?
>>>
>>> There are issues about documentation and code on github, but how about
>>> graphics?
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>
>>
>> --
>> Every good wish,
>> *Inessa Pawson*
>> Executive Director
>> Albus Code
>> ine...@albuscode.org
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>


-- 
Every good wish,
*Inessa Pawson*
Executive Director
Albus Code
ine...@albuscode.org
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[george trojan]

To Andrew Nelson:

> In the return section for fsolve the documentation states that the return
> value, `x`, is an `ndarray`.

True, my bad. There is another issue with `fsolve`: it implicitly changes
the argument  passed to `func`. Consider

def func(x):
# x = float(x)
if not np.isscalar(x) and x.shape != ():
raise ValueError('The argument must be a number or a 0-d array')
return x - 1

fsolve(func, np.array(2.0))

---ValueError
   Traceback (most recent call
last)/tmp/ipykernel_1017360/2091764495.py in   5
return x - 1  6 > 7 fsolve(func, np.array(2.0))
. . .
 ValueError: The argument must be a number or a 0-d array

I had the commented out line in my code (in real life I am calling a
library function that accepts only
numeric types, not arrays). Changing this to line to x = x.item() makes sense.
The documentation states that `func` takes at least one (possibly
vector) argument. It must take a vector.
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[Nico Schlömer]

@george trojan

The SciPy devs are very careful not to break backwards compatibility,
even if the changes are arguably useful. That's why the impact of the
numpy PR remains under the hood for SciPy users.
I'd love to see SciPy become more consistent with array
dimensionality, too, but that's a different issue.

On Wed, Sep 15, 2021 at 11:59 PM Andrew Nelson  wrote:
>
>
>
> On Thu, 16 Sep 2021, 03:25 george trojan,  wrote:
>>
>>
>> I just wrote the following code:
>>
>> twb = scipy.optimize.fsolve(phi, tdb, args=(tdb, p, w, hd_tdb, hg_tdb), 
>> xtol=1e-8)
>> tdb, p, w, hd_tdb, hg_tdb
>> twb.shape
>> print("wet-bulb temperature {:.5f} [deg K]".format(float(twb)))
>>
>> The output is
>>
>> (313.15, 101325.0, 0.009200033532084696, 40182.343155896095, 
>> 2573510.322137241)
>>
>> (1,)
>>
>> wet-bulb temperature 295.17583 [deg K]
>>
>> All arguments are floats, the function phi returns float as well. I did 
>> expect the output to be float. Instead I got a 1d array. Were my 
>> expectations wrong?
>
>
> In the return section for fsolve the documentation states that the return 
> value, `x`, is an `ndarray`.
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[Nico Schlömer]

> I was playing with this though and was a little surprised to find
> NumPy allows things like this:
>
> >>> a = np.array([1, 2, 3])
> >>> a[:] = np.array([[[5, 6, 7]]])
> >>> a
> array([5, 6, 7])

Thanks Aaron for this example! I hadn't seen this before, and indeed
the suggested PR doesn't intercept this case. Perhaps that's something
we should consider deprecating as well. I'll add a comment to the PR;
let's take it from there.

Cheers,
Nico

On Thu, Sep 16, 2021 at 2:00 AM Aaron Meurer  wrote:
>
> Presumably this also changes int(), bool(), and complex() in the same way.
>
> The array API standard (and numpy.array_api) only requires float(),
> bool(), and int() (and soon complex()) for dimension 0 arrays (the
> standard does not have scalars), in part because of this NumPy issue
> https://data-apis.org/array-api/latest/API_specification/array_object.html#float-self.
>
> On Wed, Sep 15, 2021 at 6:18 AM Nico Schlömer  
> wrote:
> >
> > Hi everyone,
> >
> > This is seeking input on PR [1] which I've worked on with @eric-wieser
> > and @seberg. It deprecates
> > ```
> > float(x)
> > ```
> > if `x` is an array of ndim > 0. (It works with all arrays of size 1
> > right now.) This aligns the behavior of float() on ndarrays with
> > float() on lists which already fails today. It also deprecates the
> > implicit conversion to float in assignment expressions like
> > ```
> > a = np.array([1, 2, 3])
> > a[0] = [5]  # deprecated, should be a[0] = 5
>
> This already gives a ValueError in NumPy 1.21.1. Do you mean a[0] =
> np.array([5]) is deprecated?
>
> I was playing with this though and was a little surprised to find
> NumPy allows things like this:
>
> >>> a = np.array([1, 2, 3])
> >>> a[:] = np.array([[[5, 6, 7]]])
> >>> a
> array([5, 6, 7])
>
> Array assignment allows some sort of reverse broadcasting? Given this
> behavior, it seems to me that a[0] = np.array([5]) actually should
> work. Or is the idea that this entire behavior would be deprecated?
>
> Aaron Meurer
>
> > ```
> > In general, the PR makes numpy a tad bit stricter on how it treats
> > scalars vs. single-item arrays.
> >
> > The change also prevents the #1 wrong usage of float(), namely for
> > extracting the scalar value from an array. One should rather use
> > `x[0]` or `x.item()` to that which doesn't convert the value to a
> > Python float.
> >
> > To estimate the impact of the PR, I looked at major numpy dependents
> > like matplotlib, scipy, pandas etc., and of course numpy itself.
> > Except scipy, all projects were virtually clean to start with. Scipy
> > needed some changes for all tests to pass without warning, and all of
> > the changes were improvements. In particular, the deprecation
> > motivates users to use actual scalars when scalars are needed, e.g.,
> > in the case of scipy, as the return value of a goal functional.
> >
> > It'd be great if you could try the branch against your own project and
> > let us know (here or in the PR) about and problems that you might
> > have.
> >
> > Thanks!
> > Nico
> >
> > [1] https://github.com/numpy/numpy/pull/10615
> > [2] https://github.com/numpy/numpy/issues/10404
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion