From ralf.gommers at gmail.com  Wed Sep  1 10:59:44 2021
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 1 Sep 2021 16:59:44 +0200
Subject: [Numpy-discussion] no community meeting today
Message-ID: <CABL7CQhw+XE7dxU-soR7SGDCDhuUr8o973zTZYZ188fHq-PHAg@mail.gmail.com>

Hi all,

Just a heads up that there's no community meeting later today. For next
time, please feel free to add topics to
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210901/feabff8b/attachment.html>

From ralf.gommers at gmail.com  Thu Sep  2 04:11:29 2021
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 2 Sep 2021 10:11:29 +0200
Subject: [Numpy-discussion] New CZI grant to support DEI initiatives in
 the scientific Python ecosystem
In-Reply-To: <CAC7J6VZRr4y1O_2KO7AaeH_B9qYg507ZPJVBSS4PLPBVUGPK8Q@mail.gmail.com>
References: <CAC7J6VZRr4y1O_2KO7AaeH_B9qYg507ZPJVBSS4PLPBVUGPK8Q@mail.gmail.com>
Message-ID: <CABL7CQjcN4J7Vd77j4dvhDQVkEwh3FG337q1GdZpnrZw-mAtdA@mail.gmail.com>

On Tue, Aug 31, 2021 at 7:28 PM Melissa Mendon?a <melissawm at gmail.com>
wrote:

> We are happy to announce the Chan Zuckerberg Initiative has awarded a
> grant to support the onboarding, inclusion, and retention of people from
> historically marginalized groups on scientific Python projects, and to
> structurally improve the community dynamics for NumPy, SciPy, Matplotlib,
> and Pandas.
>
> As a part of CZI?s Essential Open Source Software for Science program [1],
> this Diversity & Inclusion supplemental grant [2] will support the creation
> of dedicated Contributor Experience Lead positions to identify, document,
> and implement practices to foster inclusive open-source communities. This
> project will be led by Melissa Mendon?a (NumPy), with additional mentorship
> and guidance provided by Ralf Gommers (NumPy, SciPy), Hannah Aizenman and
> Thomas Caswell (Matplotlib), Matt Haberland (SciPy), and Joris Van den
> Bossche (Pandas).
>
> This is an ambitious project aiming to discover and implement activities
> that should structurally improve the community dynamics of our projects. By
> establishing these new cross-project roles, we hope to introduce a new
> collaboration model to the Scientific Python communities, allowing
> community-building work within the ecosystem to be done more efficiently
> and with greater outcomes. We also expect to develop a clearer picture of
> what works and what doesn?t in our projects to engage and retain new
> contributors, especially from historically underrepresented groups.
> Finally, we plan on producing detailed reports on the actions executed,
> explaining how they have impacted our projects in terms of representation
> and interaction with our communities.
>
> The two-year project is expected to start by November 2021, and we are
> excited to see the results from this work! You can read the full proposal
> in figshare [3] and see this announcement at the NumPy site [4].
>
Thanks for sharing the great news and for leading this project Melissa! I'm
really looking forward to seeing this get off the ground and make a
different to NumPy, Pandas, Matplotlib and SciPy.

Cheers,
Ralf


Cheers!
>
> - Melissa
>
> [1] https://chanzuckerberg.com/eoss/
> [2]
> https://cziscience.medium.com/advancing-diversity-and-inclusion-in-scientific-open-source-eaabe6a5488b
> [3]
> https://figshare.com/articles/online_resource/Advancing_an_inclusive_culture_in_the_scientific_Python_ecosystem/16548063
> [4]
> https://numpy.org/news/#advancing-an-inclusive-culture-in-the-scientific-python-ecosystem
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210902/bad4d61b/attachment.html>

From mikofski at berkeley.edu  Fri Sep  3 14:38:41 2021
From: mikofski at berkeley.edu (Dr. Mark Alexander Mikofski PhD)
Date: Fri, 3 Sep 2021 11:38:41 -0700
Subject: [Numpy-discussion] ANN: pvlib-0.9.0 released
Message-ID: <CAEqRcW0F7a8Cw9TdpgCSMK9zd35CLX9P9RmgoW+WoyPDODGQmA@mail.gmail.com>

  Dear Pythonistas and solar power enthusiasts,

On behalf of the maintainers, we're happy to announce a new release of
pvlib python:
software for simulating performance of photovoltaic solar energy systems.

*See what's new for v0.9.0:*
* https://pvlib-python.readthedocs.io/en/stable/whatsnew.html

*Releases are available from PyPI and the conda-forge channel:*
* https://pypi.org/project/pvlib/
* https://anaconda.org/conda-forge/pvlib-python

*Read the Documentation:*
* https://pvlib-python.readthedocs.io/en/stable/index.html

*Report issues & contribute:*
* https://github.com/pvlib/pvlib-python

*Highlights:*
* There are some breaking changes
<https://pvlib-python.readthedocs.io/en/stable/whatsnew.html#breaking-changes>,
so please read the Release Notes carefully before updating.
* pvlib now has a new Array class
<https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.pvsystem.Array.html>
that
represents groups of identical modules that are part of a PVSystem but have
the same orientation and mounting type.
* The PVSystem class
<https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.pvsystem.PVSystem.html>
can
now model a combination of arrays each with different orientations,
modules, and mounting types.
* pvlib completed a very successful GSoC
<https://summerofcode.withgoogle.com/>, which added several new iotools
like get_bsrn()
<https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.iotools.get_bsrn.html>
, get_pvgis_hourly()
<https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.iotools.read_pvgis_hourly.html>
, get_cams()
<https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.iotools.get_cams.html>,
and more. Special thanks to Adam R. Jensen <https://predictablysunny.com/>,
Kevin Anderson, and many reviewers who helped!
* Many bug fixes
<https://pvlib-python.readthedocs.io/en/stable/whatsnew.html#bug-fixes>
including
a fix to Perez <https://github.com/pvlib/pvlib-python/issues/1238> contributed
by Clean Power Research. Read their blog
<https://www.solaranywhere.com/2021/pvlib-models-via-solaranywhere-joins-pvlib-community/>
to
learn more about how they're contributing to pvlib. Thanks!

*The maintainers thank you for using pvlib python!*


-- 
Mark Mikofski, PhD (2005)
*Fiat Lux*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210903/9aafc66c/attachment.html>

From kshitijkalambarkar at gmail.com  Sat Sep  4 04:02:20 2021
From: kshitijkalambarkar at gmail.com (Kshitij Kalambarkar)
Date: Sat, 4 Sep 2021 13:32:20 +0530
Subject: [Numpy-discussion] np.trunc is inconsistent with array-api
Message-ID: <CAGhStggXJ8L5ptdTxB6bcYz9SHHtsX4hKb6T35xjaPQLHJ8Yzg@mail.gmail.com>

Hi,

np.trunc returns floating dtype output even for integral dtype input. As
per array-api, it should preserve the input dtype.

Note: This is also true for np.rint, np.fix, np.ceil, np.floor

Reference: https://github.com/numpy/numpy/issues/19464

Possible Fix:
1. We update the behaviour directly with an update to release note.
2. We add a FutureWarning and update the behaviour in a future release.

This email is to gauge the preference for the fix.

Thank You!

Regards,
Kshiteej K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210904/503546d4/attachment.html>

From amardeepjk at gmail.com  Sun Sep  5 05:55:11 2021
From: amardeepjk at gmail.com (Amardeep Singh)
Date: Sun, 5 Sep 2021 17:55:11 +0800
Subject: [Numpy-discussion] Help Regarding Debugging Cython Code
Message-ID: <CAJmcdX7pvpjv9ZG4XjSqXv-Uup5pa6d512ZWcmNQa8MeS8KTcQ@mail.gmail.com>

Hi Team

If some one has setup to debug cython code can  you please share
the details.
I am using ubuntu 20.4 .
Not sure why gdb not picking up breakpoints.

I am able to debug c extensions but not cython code.

Thx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210905/67442ca4/attachment.html>

From matti.picus at gmail.com  Sun Sep  5 08:57:09 2021
From: matti.picus at gmail.com (Matti Picus)
Date: Sun, 5 Sep 2021 15:57:09 +0300
Subject: [Numpy-discussion] Help Regarding Debugging Cython Code
In-Reply-To: <CAJmcdX7pvpjv9ZG4XjSqXv-Uup5pa6d512ZWcmNQa8MeS8KTcQ@mail.gmail.com>
References: <CAJmcdX7pvpjv9ZG4XjSqXv-Uup5pa6d512ZWcmNQa8MeS8KTcQ@mail.gmail.com>
Message-ID: <9aa30a42-364a-5ca8-c7c8-8f539edf7414@gmail.com>


On 5/9/21 12:55 pm, Amardeep Singh wrote:
> Hi Team
>
> If?some one has setup?to debug cython code can? you please share 
> the?details.
> I am using ubuntu 20.4 .
> Not sure why gdb not picking?up breakpoints.
>
> I am able to debug c extensions?but not cython code.
>
> Thx


There are a number of ways to set up for debugging. The one that works 
for me is to do


git clean -xfdd

CFLAGS='-O0 -g3' python runtests.py -b

gdb --args python runtests.py -t file/I/with/the/test/I/want.py


The "git clean" should make sure you are not using pre-compiled 
c-extensions.

There are variants of this if you are using an IDE or like to use 
setup.py directly


Matti


From ralf.gommers at gmail.com  Sun Sep  5 15:08:55 2021
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 5 Sep 2021 21:08:55 +0200
Subject: [Numpy-discussion] np.trunc is inconsistent with array-api
In-Reply-To: <CAGhStggXJ8L5ptdTxB6bcYz9SHHtsX4hKb6T35xjaPQLHJ8Yzg@mail.gmail.com>
References: <CAGhStggXJ8L5ptdTxB6bcYz9SHHtsX4hKb6T35xjaPQLHJ8Yzg@mail.gmail.com>
Message-ID: <CABL7CQi--pv4UKiM8pORkAsoJUfkwWYsgz8+DJvnGcWDOFSQaA@mail.gmail.com>

On Sat, Sep 4, 2021 at 10:02 AM Kshitij Kalambarkar <
kshitijkalambarkar at gmail.com> wrote:

> Hi,
>
> np.trunc returns floating dtype output even for integral dtype input. As
> per array-api, it should preserve the input dtype.
>

Just a note that it's not compatibility with the array API standard that's
the main driver for the change here (that would be handled in
`numpy.array_api.trunc`, not `numpy.trunc`). But it's just unwanted
behavior, so an improvement to `numpy.trunc` is also desirable.


> Note: This is also true for np.rint, np.fix, np.ceil, np.floor
>
> Reference: https://github.com/numpy/numpy/issues/19464
>
> Possible Fix:
> 1. We update the behaviour directly with an update to release note.
> 2. We add a FutureWarning and update the behaviour in a future release.
>

I'm fine with (1), because (a) it can be considered a bug fix, (b) it's
unlikely to break anything, and (c) a FutureWarning is not too helpful
because there's no way to update existing code to be forward-proof and
remove the warning.

Cheers,
Ralf


> This email is to gauge the preference for the fix.
>
> Thank You!
>
> Regards,
> Kshiteej K
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210905/32a5d922/attachment.html>

From sebastian at sipsolutions.net  Tue Sep  7 19:09:34 2021
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Tue, 07 Sep 2021 18:09:34 -0500
Subject: [Numpy-discussion] NumPy Development Meeting Wednesday - Triage
 Focus
Message-ID: <b7969fa0fb21f848d917c8af4a07eccf734b52ba.camel@sipsolutions.net>

Hi all,

Our bi-weekly triage-focused NumPy development meeting is Wednesday,
September 8th at 9 am Pacific Time (16:00 UTC).
Everyone is invited to join in and edit the work-in-progress meeting
topics and notes:
https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg

I encourage everyone to notify us of issues or PRs that you feel should
be prioritized, discussed, or reviewed.

Best regards

Sebastian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210907/53814751/attachment.sig>

From melissawm at gmail.com  Wed Sep  8 10:40:23 2021
From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=)
Date: Wed, 8 Sep 2021 11:40:23 -0300
Subject: [Numpy-discussion] Newcomer's meeting: September 9, 4PM UTC
In-Reply-To: <CAC7J6Vbhwa9EaxypmCHXtZMVa1QMjOszKPENYziu1t4yj3+LDA@mail.gmail.com>
References: <CAC7J6Vbu+r1r-2TM5zOcypN_v5f1uMDcM_61xTdFfxkRmZLPug@mail.gmail.com>
 <CAC7J6Vbhwa9EaxypmCHXtZMVa1QMjOszKPENYziu1t4yj3+LDA@mail.gmail.com>
Message-ID: <CAC7J6VaqP_Tf4cosfkRjMa5PKtkasnVS_pj4ck6yKrv6bJMM+g@mail.gmail.com>

Hi all!

Our next Newcomer's Meeting is on Thursday,
*September 9, at 4pm UTC.*

This is an informal meeting with no agenda to ask questions, get to know
other people and (hopefully) figure out ways to contribute to NumPy. Feel
free to join if you are lurking around but found it hard to start
contributing - we'll do our best to support you.

If you wish to join on Zoom, use this link: https://zoom.us/j/6345425936

Hope to see you around!

** You can click this link to get the correct time at your timezone:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Newcomers%27+Meeting&iso=20210909T16&p1=1440&ah=1
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Newcomer%27s+Meeting&iso=20210617T16&p1=1440&ah=1>

*** You can add the NumPy community calendar to your google calendar by
clicking this link: https://calendar.google.com/calendar
/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20

- Melissa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210908/2b4f19a9/attachment.html>

From asmeurer at gmail.com  Thu Sep  9 18:49:45 2021
From: asmeurer at gmail.com (Aaron Meurer)
Date: Thu, 9 Sep 2021 16:49:45 -0600
Subject: [Numpy-discussion] np.trunc is inconsistent with array-api
In-Reply-To: <CAGhStggXJ8L5ptdTxB6bcYz9SHHtsX4hKb6T35xjaPQLHJ8Yzg@mail.gmail.com>
References: <CAGhStggXJ8L5ptdTxB6bcYz9SHHtsX4hKb6T35xjaPQLHJ8Yzg@mail.gmail.com>
Message-ID: <CAKgW=6JDDrkE5CRQ3hXMGGfcS3Vbv+F8pbWBwhN2dkvLJByVEQ@mail.gmail.com>

On Sat, Sep 4, 2021 at 2:03 AM Kshitij Kalambarkar
<kshitijkalambarkar at gmail.com> wrote:
>
> Hi,
>
> np.trunc returns floating dtype output even for integral dtype input. As per array-api, it should preserve the input dtype.
>
> Note: This is also true for np.rint, np.fix, np.ceil, np.floor

Probably worth noting that np.round (np.around) already returns the
same data type as the input.

Aaron Meurer

>
> Reference: https://github.com/numpy/numpy/issues/19464
>
> Possible Fix:
> 1. We update the behaviour directly with an update to release note.
> 2. We add a FutureWarning and update the behaviour in a future release.
>
> This email is to gauge the preference for the fix.
>
> Thank You!
>
> Regards,
> Kshiteej K
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

From sebastian at sipsolutions.net  Thu Sep  9 21:11:26 2021
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Thu, 09 Sep 2021 20:11:26 -0500
Subject: [Numpy-discussion] np.trunc is inconsistent with array-api
In-Reply-To: <CABL7CQi--pv4UKiM8pORkAsoJUfkwWYsgz8+DJvnGcWDOFSQaA@mail.gmail.com>
References: <CAGhStggXJ8L5ptdTxB6bcYz9SHHtsX4hKb6T35xjaPQLHJ8Yzg@mail.gmail.com>
 <CABL7CQi--pv4UKiM8pORkAsoJUfkwWYsgz8+DJvnGcWDOFSQaA@mail.gmail.com>
Message-ID: <d82ee0f8ccd23b7bf984e2ca72472244678a2d3f.camel@sipsolutions.net>

On Sun, 2021-09-05 at 21:08 +0200, Ralf Gommers wrote:
> On Sat, Sep 4, 2021 at 10:02 AM Kshitij Kalambarkar <
> kshitijkalambarkar at gmail.com> wrote:
> 
> > Hi,
> > 
> > np.trunc returns floating dtype output even for integral dtype
> > input. As
> > per array-api, it should preserve the input dtype.
> > 
> 
> Just a note that it's not compatibility with the array API standard
> that's
> the main driver for the change here (that would be handled in
> `numpy.array_api.trunc`, not `numpy.trunc`). But it's just unwanted
> behavior, so an improvement to `numpy.trunc` is also desirable.
> 
> 
> > Note: This is also true for np.rint, np.fix, np.ceil, np.floor
> > 
> > Reference: https://github.com/numpy/numpy/issues/19464
> > 
> > Possible Fix:
> > 1. We update the behaviour directly with an update to release note.
> > 2. We add a FutureWarning and update the behaviour in a future
> > release.
> > 
> 
> I'm fine with (1), because (a) it can be considered a bug fix, (b)
> it's
> unlikely to break anything, and (c) a FutureWarning is not too
> helpful
> because there's no way to update existing code to be forward-proof
> and
> remove the warning.

One work-around might be to pass `dtype=arr.dtype` probably, but that
would fail on current NumPy.  So the only choice would probably be
explicitly not calling `trunc`.
?
So, I agree, I lean towards moving forward here.  (Unless anyone has
e.g. an example of code that would break?)


There is a tiny possibility of catastrophic failure (silent wrong
results).  But my best guess is that the vast majority of code probably
will not notice.
E.g. one pattern that is probably extremely common is to cast to
integer right after the call to `trunc`.

Cheers,

Sebastian


> 
> Cheers,
> Ralf
> 
> 
> > This email is to gauge the preference for the fix.
> > 
> > Thank You!
> > 
> > Regards,
> > Kshiteej K
> > 
> > 
> > 
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> > 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210909/15c43fdb/attachment.sig>

From asmeurer at gmail.com  Fri Sep 10 16:51:06 2021
From: asmeurer at gmail.com (Aaron Meurer)
Date: Fri, 10 Sep 2021 14:51:06 -0600
Subject: [Numpy-discussion] np.trunc is inconsistent with array-api
In-Reply-To: <d82ee0f8ccd23b7bf984e2ca72472244678a2d3f.camel@sipsolutions.net>
References: <CAGhStggXJ8L5ptdTxB6bcYz9SHHtsX4hKb6T35xjaPQLHJ8Yzg@mail.gmail.com>
 <CABL7CQi--pv4UKiM8pORkAsoJUfkwWYsgz8+DJvnGcWDOFSQaA@mail.gmail.com>
 <d82ee0f8ccd23b7bf984e2ca72472244678a2d3f.camel@sipsolutions.net>
Message-ID: <CAKgW=6KvXgT6HnqffAAEoFEzJMTnL1D3HMJd44earxkL+VGFSw@mail.gmail.com>

On Thu, Sep 9, 2021 at 7:11 PM Sebastian Berg
<sebastian at sipsolutions.net> wrote:
>
> On Sun, 2021-09-05 at 21:08 +0200, Ralf Gommers wrote:
> > On Sat, Sep 4, 2021 at 10:02 AM Kshitij Kalambarkar <
> > kshitijkalambarkar at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > np.trunc returns floating dtype output even for integral dtype
> > > input. As
> > > per array-api, it should preserve the input dtype.
> > >
> >
> > Just a note that it's not compatibility with the array API standard
> > that's
> > the main driver for the change here (that would be handled in
> > `numpy.array_api.trunc`, not `numpy.trunc`). But it's just unwanted
> > behavior, so an improvement to `numpy.trunc` is also desirable.
> >
> >
> > > Note: This is also true for np.rint, np.fix, np.ceil, np.floor
> > >
> > > Reference: https://github.com/numpy/numpy/issues/19464
> > >
> > > Possible Fix:
> > > 1. We update the behaviour directly with an update to release note.
> > > 2. We add a FutureWarning and update the behaviour in a future
> > > release.
> > >
> >
> > I'm fine with (1), because (a) it can be considered a bug fix, (b)
> > it's
> > unlikely to break anything, and (c) a FutureWarning is not too
> > helpful
> > because there's no way to update existing code to be forward-proof
> > and
> > remove the warning.
>
> One work-around might be to pass `dtype=arr.dtype` probably, but that
> would fail on current NumPy.  So the only choice would probably be
> explicitly not calling `trunc`.
>
> So, I agree, I lean towards moving forward here.  (Unless anyone has
> e.g. an example of code that would break?)
>
>
> There is a tiny possibility of catastrophic failure (silent wrong
> results).  But my best guess is that the vast majority of code probably
> will not notice.
> E.g. one pattern that is probably extremely common is to cast to
> integer right after the call to `trunc`.

If that's true, then this may actually fix some bugs. If some code
does trunc(x).astype(int) and x could be float or int, then the result
will be wrong if x is int64 with values larger than ~2**54, which
cannot fit exactly into float64, e.g.,

>>> np.trunc(11962686510203121).astype(int)
11962686510203120

I'm not sure I understand how changing this could lead to new wrong results.

Aaron Meurer

>
> Cheers,
>
> Sebastian
>
>
> >
> > Cheers,
> > Ralf
> >
> >
> > > This email is to gauge the preference for the fix.
> > >
> > > Thank You!
> > >
> > > Regards,
> > > Kshiteej K
> > >
> > >
> > >
> > > _______________________________________________
> > > NumPy-Discussion mailing list
> > > NumPy-Discussion at python.org
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

From sebastian at sipsolutions.net  Fri Sep 10 18:33:43 2021
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Fri, 10 Sep 2021 17:33:43 -0500
Subject: [Numpy-discussion] np.trunc is inconsistent with array-api
In-Reply-To: <CAKgW=6KvXgT6HnqffAAEoFEzJMTnL1D3HMJd44earxkL+VGFSw@mail.gmail.com>
References: <CAGhStggXJ8L5ptdTxB6bcYz9SHHtsX4hKb6T35xjaPQLHJ8Yzg@mail.gmail.com>
 <CABL7CQi--pv4UKiM8pORkAsoJUfkwWYsgz8+DJvnGcWDOFSQaA@mail.gmail.com>
 <d82ee0f8ccd23b7bf984e2ca72472244678a2d3f.camel@sipsolutions.net>
 <CAKgW=6KvXgT6HnqffAAEoFEzJMTnL1D3HMJd44earxkL+VGFSw@mail.gmail.com>
Message-ID: <417a229697527efeb8ba1642be3dbd38e4707667.camel@sipsolutions.net>

On Fri, 2021-09-10 at 14:51 -0600, Aaron Meurer wrote:
> On Thu, Sep 9, 2021 at 7:11 PM Sebastian Berg
> <sebastian at sipsolutions.net> wrote:
> > 
> > On Sun, 2021-09-05 at 21:08 +0200, Ralf Gommers wrote:
> > > On Sat, Sep 4, 2021 at 10:02 AM Kshitij Kalambarkar <
> > > kshitijkalambarkar at gmail.com> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > np.trunc returns floating dtype output even for integral dtype
> > > > input. As
> > > > per array-api, it should preserve the input dtype.
> > > > 
> > > 
> > > Just a note that it's not compatibility with the array API
> > > standard
> > > that's
> > > the main driver for the change here (that would be handled in
> > > `numpy.array_api.trunc`, not `numpy.trunc`). But it's just
> > > unwanted
> > > behavior, so an improvement to `numpy.trunc` is also desirable.
> > > 
> > > 
> > > > Note: This is also true for np.rint, np.fix, np.ceil, np.floor
> > > > 
> > > > Reference: https://github.com/numpy/numpy/issues/19464
> > > > 
> > > > Possible Fix:
> > > > 1. We update the behaviour directly with an update to release
> > > > note.
> > > > 2. We add a FutureWarning and update the behaviour in a future
> > > > release.
> > > > 
> > > 
> > > I'm fine with (1), because (a) it can be considered a bug fix,
> > > (b)
> > > it's
> > > unlikely to break anything, and (c) a FutureWarning is not too
> > > helpful
> > > because there's no way to update existing code to be forward-
> > > proof
> > > and
> > > remove the warning.
> > 
> > One work-around might be to pass `dtype=arr.dtype` probably, but
> > that
> > would fail on current NumPy.? So the only choice would probably be
> > explicitly not calling `trunc`.
> > 
> > So, I agree, I lean towards moving forward here.? (Unless anyone
> > has
> > e.g. an example of code that would break?)
> > 
> > 
> > There is a tiny possibility of catastrophic failure (silent wrong
> > results).? But my best guess is that the vast majority of code
> > probably
> > will not notice.
> > E.g. one pattern that is probably extremely common is to cast to
> > integer right after the call to `trunc`.
> 
> If that's true, then this may actually fix some bugs. If some code
> does trunc(x).astype(int) and x could be float or int, then the
> result
> will be wrong if x is int64 with values larger than ~2**54, which
> cannot fit exactly into float64, e.g.,

Sure.

> > > > np.trunc(11962686510203121).astype(int)
> 11962686510203120
> 
> I'm not sure I understand how changing this could lead to new wrong
> results.
> 

I can't think of a reasonable way either, but e.g. code could run into
integer overflows.  It seems all very unlikely, though. 

I was thinking a bit in the direction of simple unsafe operations:

     res = np.trunc(arr)
     res *= 0.5  # will error if res is integer

But most should error and not return bad results...

In any case: I will worry if anyone shows a real-world/likely example
for how it can go wrong.  And right now, that seems fairly unlikely.

Cheers,

Sebastian


> Aaron Meurer
> 
> > 
> > Cheers,
> > 
> > Sebastian
> > 
> > 
> > > 
> > > Cheers,
> > > Ralf
> > > 
> > > 
> > > > This email is to gauge the preference for the fix.
> > > > 
> > > > Thank You!
> > > > 
> > > > Regards,
> > > > Kshiteej K
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > NumPy-Discussion mailing list
> > > > NumPy-Discussion at python.org
> > > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > > > 
> > > _______________________________________________
> > > NumPy-Discussion mailing list
> > > NumPy-Discussion at python.org
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > 
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210910/657f164c/attachment.sig>

From melissawm at gmail.com  Sat Sep 11 08:20:49 2021
From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=)
Date: Sat, 11 Sep 2021 09:20:49 -0300
Subject: [Numpy-discussion] Documentation Team meeting - Monday September 13
In-Reply-To: <CAC7J6VYP+RVa5J=ZkXShfdWi7xCeTWuqw5zjzmftT5DYE8xeAQ@mail.gmail.com>
References: <CAC7J6Vbkch+=wQcEbJgELAphM2d2552Ywr2txrbinUR-khTR=g@mail.gmail.com>
 <CAC7J6VY9k_EGL-adWpeHLvFOEG6EBy3wauhD8cZ5vmL-JDxA0Q@mail.gmail.com>
 <CAC7J6VaNwZDbtt4FP6mX_-+iD_d=_4VVcjdGiaJj=q7eWCHewA@mail.gmail.com>
 <CAC7J6VZ2D8q0s7+rpKv7HYh9oBqwOQnUP_HjwKCjMtAnfi60Og@mail.gmail.com>
 <CAC7J6VY=vgKXySL1Euy30ZNzqkqvcr4Za1L04JZv-GCk87c1AQ@mail.gmail.com>
 <CAC7J6Vbq0vtd5JH6MXvcSj4A4aZjg+x=QdHvPyQGeGcmpp8JYg@mail.gmail.com>
 <CAC7J6VZ_+uh967zGc7qA6+KWKsP=gZ8bZecrJ9Hq9oG0JTzsOg@mail.gmail.com>
 <CAC7J6VZkder9wiEmE+Cm5Lxg0zt0t_a-KwfuvcCXZG91Wk+7kA@mail.gmail.com>
 <CAC7J6VYyt4c2qcp92iE8_BMF70cUC3-ZX5E5mqNa0zVAFryvmQ@mail.gmail.com>
 <CAC7J6VZq1DLDk--F+S6F50DHMMXOaWo6cbpSau7APHe22X_c9w@mail.gmail.com>
 <CAC7J6VaegMEY9dvMeRSe2YY=AUEJYkXNNF-KTy89zyE6LgHo5A@mail.gmail.com>
 <CAC7J6VY4_X-MyXajy0KryML03KoryKR9n5dsf5bupgv7noukUg@mail.gmail.com>
 <CAC7J6Va3n9Hdym+RmscOkDyf1ukH+DDtCv7N9D8y0cX1a+uC-A@mail.gmail.com>
 <CAC7J6VZX57n+_nWL-dKe4YzqY=Nc1=LYRXkNv8+JcP=q3Vyqog@mail.gmail.com>
 <CAC7J6Vb5uGp-gEMudbbiWSBKo1gyMsq03M4hz9mnNYir9GcqXw@mail.gmail.com>
 <CAC7J6Va3g7Pqrs=Hxtgg6GKHhZwErz4PPiKLw0YL-R2HUkWprQ@mail.gmail.com>
 <CAC7J6Vay+j5SsbXsJkCh2K5aeR6a8HkrkFpzDWoPkOfH=a9OkA@mail.gmail.com>
 <CAC7J6VYzL4+hxf7=1NfxHx7tVyfQci2iNNr7=gCRgJkMVXuiyQ@mail.gmail.com>
 <CAC7J6VaBg=C-J4TgiUOSeHmE5qRM0O_Fzxsfyyozgczqsihv+g@mail.gmail.com>
 <CAC7J6VaCrBzE5SsxmmkOLKukPjJCc_mU_7JZS+=2VQ7vE8RVsQ@mail.gmail.com>
 <CAC7J6VZOhGHcXuNyOM4d2fd=kSXueBdfCuCUMrrSDC96Qj4+Yg@mail.gmail.com>
 <CAC7J6VanaH2MTi8JFKZaiLksMs6Jsi5yCHO8tSD31eifis+1Gw@mail.gmail.com>
 <CAC7J6VaxqCbTWqhkbzim-8HSbF5F7baSvtVr6YMACGWVRGt=vg@mail.gmail.com>
 <CAC7J6VZNa+8ap+fUwyCxsg0Kj+BXpadBdG=8E-1STSovREXyoQ@mail.gmail.com>
 <CAC7J6VZs3dxp6qPP-k41z7hEA9FcuJh+w5zVFW-=weKTXrO=jQ@mail.gmail.com>
 <CAC7J6VawxvVYVT9WAthQg9kA2mMP6xaHC_prPifBx78k=tRv8A@mail.gmail.com>
 <CAC7J6VbkhqwRdXodL3D3YCt-F_vyt2z78WjZ5w3VmhesQm0-9A@mail.gmail.com>
 <CAC7J6VbeN3x_sqn9soneCVwfvU3-VL0R9VpSyF5oW-dDAd4r2A@mail.gmail.com>
 <CAC7J6VZL+MEXkuKgeqtfdgb4ewVg3PCdHQpwQGtsci2VXX8_kA@mail.gmail.com>
 <CAC7J6VZVL9uTuv-eAY=cnLkdc-niCvOwbB2iRVqYSo2qwX1SpQ@mail.gmail.com>
 <CAC7J6VYP+RVa5J=ZkXShfdWi7xCeTWuqw5zjzmftT5DYE8xeAQ@mail.gmail.com>
Message-ID: <CAC7J6VaPhYJPRKufsk5qxvn1353KrSOU7c=M20ErJtMMu8ymaw@mail.gmail.com>

Hi all!

Our next Documentation Team meeting will be tomorrow - *Monday, September
13* at ***4PM UTC***.

All are welcome - you don't need to already be a contributor to join. If
you have questions or are curious about what we're doing, we'll be happy to
meet you!

If you wish to join on Zoom, use this link:

https://zoom.us/j/96219574921?pwd=VTRNeGwwOUlrYVNYSENpVVBRRjlkZz09#success

Here's the permanent hackmd document with the meeting notes (still being
updated in the next few days!):

https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg
<https://www.google.com/url?q=https%3A%2F%2Fhackmd.io%2FoB_boakvRqKR-_2jRV-Qjg&sa=D&usd=2&usg=AFQjCNGIOzVwlfDFd6YAgBwVUjmjQKWRSw>

Hope to see you around!

** You can click this link to get the correct time at your timezone:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentation+Team+Meeting&iso=20210913T16&p1=1440&ah=1

*** You can add the NumPy community calendar to your google calendar by
clicking this link: https://calendar.google.com/calendar
/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20

- Melissa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210911/5f54394a/attachment-0001.html>

From holamgadol at gmail.com  Sat Sep 11 09:05:43 2021
From: holamgadol at gmail.com (Holam Gadol)
Date: Sat, 11 Sep 2021 16:05:43 +0300
Subject: [Numpy-discussion] graphic design contribution
Message-ID: <CACQODw4DcRy54hqnerCB5R_up_i-w0ygcrTugnzSPd9c+N2ZAg@mail.gmail.com>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210911/a0232025/attachment.html>

From albuscode at gmail.com  Sun Sep 12 23:11:00 2021
From: albuscode at gmail.com (Inessa Pawson)
Date: Sun, 12 Sep 2021 23:11:00 -0400
Subject: [Numpy-discussion] NumPy-Discussion Digest, Vol 180, Issue 9
In-Reply-To: <mailman.21.1631376003.13839.numpy-discussion@python.org>
References: <mailman.21.1631376003.13839.numpy-discussion@python.org>
Message-ID: <CAPBcLCEj-ykgt+iQiS1Fft-XXuLKa1syHPCYaYODRxvxFW1BSQ@mail.gmail.com>

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 <numpy-discussion-request at python.org>
wrote:

> Send NumPy-Discussion mailing list submissions to
>         numpy-discussion at 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-request at python.org
>
> You can reach the person managing the list at
>         numpy-discussion-owner at 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 <holamgadol at gmail.com>
> To: numpy-discussion at 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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>


-- 
Every good wish,
*Inessa Pawson*
Executive Director
Albus Code
inessa at albuscode.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210912/fe312efe/attachment.html>

From holamgadol at gmail.com  Mon Sep 13 16:11:07 2021
From: holamgadol at gmail.com (Holam Gadol)
Date: Mon, 13 Sep 2021 23:11:07 +0300
Subject: [Numpy-discussion] graphic design contribution
In-Reply-To: <CAPBcLCEj-ykgt+iQiS1Fft-XXuLKa1syHPCYaYODRxvxFW1BSQ@mail.gmail.com>
References: <mailman.21.1631376003.13839.numpy-discussion@python.org>
 <CAPBcLCEj-ykgt+iQiS1Fft-XXuLKa1syHPCYaYODRxvxFW1BSQ@mail.gmail.com>
Message-ID: <CACQODw46S4YhS0qx5v=KMmWhaRwj00-C_ruxcMXLuJUjU808TA@mail.gmail.com>

Thank you for replying, Inessa.

Refining infographics from the issue #435
<https://github.com/numpy/numpy.org/issues/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 <albuscode at gmail.com>:

> 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 <numpy-discussion-request at python.org>
> wrote:
>
>> Send NumPy-Discussion mailing list submissions to
>>         numpy-discussion at 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-request at python.org
>>
>> You can reach the person managing the list at
>>         numpy-discussion-owner at 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 <holamgadol at gmail.com>
>> To: numpy-discussion at 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 at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>
>
> --
> Every good wish,
> *Inessa Pawson*
> Executive Director
> Albus Code
> inessa at albuscode.org
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210913/1e7e7f80/attachment.html>

From sebastian at sipsolutions.net  Tue Sep 14 23:51:11 2021
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Tue, 14 Sep 2021 22:51:11 -0500
Subject: [Numpy-discussion] NumPy Community Meeting Wednesday
Message-ID: <935b4640887dc791be8fa4e66dc1b0f71e0be66e.camel@sipsolutions.net>

Hi all,

There will be a NumPy Community meeting Wednesday September 15th at
20:00 UTC. Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at:

https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both

Best wishes

Sebastian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210914/2c779744/attachment.sig>

From nico.schloemer at gmail.com  Wed Sep 15 08:18:05 2021
From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=)
Date: Wed, 15 Sep 2021 14:18:05 +0200
Subject: [Numpy-discussion] deprecating float(x) for ndim > 0
Message-ID: <CAK6Z60dFJN6cuCrbKC_Ktn00UgD28nsT-4yZT1Oci3Fo9z=a6g@mail.gmail.com>

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

From george.trojan at gmail.com  Wed Sep 15 13:25:19 2021
From: george.trojan at gmail.com (george trojan)
Date: Wed, 15 Sep 2021 17:25:19 +0000
Subject: [Numpy-discussion] deprecating float(x) for ndim > 0
Message-ID: <CAK6fgyEJgvNMxeFPkuq6Vcb1sUiFPpn+C0Wriv1i_JBYdx03NA@mail.gmail.com>

Responding to the post by nico.schloemer at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210915/8f0dfbe1/attachment.html>

From shoyer at gmail.com  Wed Sep 15 13:41:34 2021
From: shoyer at gmail.com (Stephan Hoyer)
Date: Wed, 15 Sep 2021 10:41:34 -0700
Subject: [Numpy-discussion] deprecating float(x) for ndim > 0
In-Reply-To: <CAK6Z60dFJN6cuCrbKC_Ktn00UgD28nsT-4yZT1Oci3Fo9z=a6g@mail.gmail.com>
References: <CAK6Z60dFJN6cuCrbKC_Ktn00UgD28nsT-4yZT1Oci3Fo9z=a6g@mail.gmail.com>
Message-ID: <CAEQ_TvfOdSiONLzT8rtn+C2=eRRFAjvoMmvejSOn_snRTVa4UA@mail.gmail.com>

On Wed, Sep 15, 2021 at 5:18 AM Nico Schl?mer <nico.schloemer at gmail.com>
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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210915/7b52327e/attachment.html>

From einstein.edison at gmail.com  Wed Sep 15 13:47:09 2021
From: einstein.edison at gmail.com (Hameer Abbasi)
Date: Wed, 15 Sep 2021 19:47:09 +0200
Subject: [Numpy-discussion] deprecating float(x) for ndim > 0
In-Reply-To: <CAK6Z60dFJN6cuCrbKC_Ktn00UgD28nsT-4yZT1Oci3Fo9z=a6g@mail.gmail.com>
References: <CAK6Z60dFJN6cuCrbKC_Ktn00UgD28nsT-4yZT1Oci3Fo9z=a6g@mail.gmail.com>
Message-ID: <AAFE1F9B-2E74-4AFA-9171-773EDB9C79AE@gmail.com>

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 <nico.schloemer at gmail.com>:
> 
> 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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion


From sebastian at sipsolutions.net  Wed Sep 15 17:42:45 2021
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Wed, 15 Sep 2021 16:42:45 -0500
Subject: [Numpy-discussion] deprecating float(x) for ndim > 0
In-Reply-To: <CAK6fgyEJgvNMxeFPkuq6Vcb1sUiFPpn+C0Wriv1i_JBYdx03NA@mail.gmail.com>
References: <CAK6fgyEJgvNMxeFPkuq6Vcb1sUiFPpn+C0Wriv1i_JBYdx03NA@mail.gmail.com>
Message-ID: <6bbf5ff41f2b7e4deff147043aa61dc1b7e544e2.camel@sipsolutions.net>

On Wed, 2021-09-15 at 17:25 +0000, george trojan wrote:
> Responding to the post by nico.schloemer at 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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210915/86535e28/attachment-0001.sig>

From andyfaff at gmail.com  Wed Sep 15 17:58:02 2021
From: andyfaff at gmail.com (Andrew Nelson)
Date: Thu, 16 Sep 2021 07:58:02 +1000
Subject: [Numpy-discussion] deprecating float(x) for ndim > 0
In-Reply-To: <CAK6fgyEJgvNMxeFPkuq6Vcb1sUiFPpn+C0Wriv1i_JBYdx03NA@mail.gmail.com>
References: <CAK6fgyEJgvNMxeFPkuq6Vcb1sUiFPpn+C0Wriv1i_JBYdx03NA@mail.gmail.com>
Message-ID: <CAAbtOZeqMRtKWmuVrcjcLg6bUxSsV3ChkJK9PmPPB2s8cyiX5w@mail.gmail.com>

On Thu, 16 Sep 2021, 03:25 george trojan, <george.trojan at gmail.com> 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`.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210916/e2791e0f/attachment.html>

From asmeurer at gmail.com  Wed Sep 15 19:59:24 2021
From: asmeurer at gmail.com (Aaron Meurer)
Date: Wed, 15 Sep 2021 17:59:24 -0600
Subject: [Numpy-discussion] deprecating float(x) for ndim > 0
In-Reply-To: <CAK6Z60dFJN6cuCrbKC_Ktn00UgD28nsT-4yZT1Oci3Fo9z=a6g@mail.gmail.com>
References: <CAK6Z60dFJN6cuCrbKC_Ktn00UgD28nsT-4yZT1Oci3Fo9z=a6g@mail.gmail.com>
Message-ID: <CAKgW=6+b7qmKr7qfTRRczBn7TYQ87HxcWjrOPhU0=HjK8W8vkQ@mail.gmail.com>

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 <nico.schloemer at gmail.com> 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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

From albuscode at gmail.com  Wed Sep 15 22:02:37 2021
From: albuscode at gmail.com (Inessa Pawson)
Date: Wed, 15 Sep 2021 22:02:37 -0400
Subject: [Numpy-discussion] graphic design contribution to NumPy
In-Reply-To: <mailman.20.1631635202.26072.numpy-discussion@python.org>
References: <mailman.20.1631635202.26072.numpy-discussion@python.org>
Message-ID: <CAPBcLCG=4gw31R_p_9zAULGGudDEgWkV6Ke7sbO-ViSsMiZFkA@mail.gmail.com>

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 <https://github.com/numpy/numpy.org/issues/435>.

On Tue, Sep 14, 2021 at 12:00 PM <numpy-discussion-request at python.org>
wrote:

> Send NumPy-Discussion mailing list submissions to
>         numpy-discussion at 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-request at python.org
>
> You can reach the person managing the list at
>         numpy-discussion-owner at 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 <holamgadol at gmail.com>
> To: Discussion of Numerical Python <numpy-discussion at python.org>
> 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
> <https://github.com/numpy/numpy.org/issues/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 <albuscode at gmail.com>:
>
>> 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 <numpy-discussion-request at python.org>
>> wrote:
>>
>>> Send NumPy-Discussion mailing list submissions to
>>>         numpy-discussion at 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-request at python.org
>>>
>>> You can reach the person managing the list at
>>>         numpy-discussion-owner at 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 <holamgadol at gmail.com>
>>> To: numpy-discussion at 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 at python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>
>>
>> --
>> Every good wish,
>> *Inessa Pawson*
>> Executive Director
>> Albus Code
>> inessa at albuscode.org
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>


-- 
Every good wish,
*Inessa Pawson*
Executive Director
Albus Code
inessa at albuscode.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210915/394e499f/attachment-0001.html>

From george.trojan at gmail.com  Thu Sep 16 01:31:59 2021
From: george.trojan at gmail.com (george trojan)
Date: Thu, 16 Sep 2021 05:31:59 +0000
Subject: [Numpy-discussion] deprecating float(x) for ndim > 0
Message-ID: <CAK6fgyHqs+SN04++Ou8PaKXxQa8+RXAePsV+vYE_8EWTFrE3Qg@mail.gmail.com>

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 <module>      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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210916/6fdfda96/attachment.html>

From nico.schloemer at gmail.com  Thu Sep 16 02:16:52 2021
From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=)
Date: Thu, 16 Sep 2021 08:16:52 +0200
Subject: [Numpy-discussion] deprecating float(x) for ndim > 0
In-Reply-To: <CAAbtOZeqMRtKWmuVrcjcLg6bUxSsV3ChkJK9PmPPB2s8cyiX5w@mail.gmail.com>
References: <CAK6fgyEJgvNMxeFPkuq6Vcb1sUiFPpn+C0Wriv1i_JBYdx03NA@mail.gmail.com>
 <CAAbtOZeqMRtKWmuVrcjcLg6bUxSsV3ChkJK9PmPPB2s8cyiX5w@mail.gmail.com>
Message-ID: <CAK6Z60ej4gqSEhGw_Cfb2dt_xD0ZgdvUOpL6-4ZGwUJCVer-dQ@mail.gmail.com>

@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 <andyfaff at gmail.com> wrote:
>
>
>
> On Thu, 16 Sep 2021, 03:25 george trojan, <george.trojan at gmail.com> 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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

From nico.schloemer at gmail.com  Thu Sep 16 02:31:54 2021
From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=)
Date: Thu, 16 Sep 2021 08:31:54 +0200
Subject: [Numpy-discussion] deprecating float(x) for ndim > 0
In-Reply-To: <CAKgW=6+b7qmKr7qfTRRczBn7TYQ87HxcWjrOPhU0=HjK8W8vkQ@mail.gmail.com>
References: <CAK6Z60dFJN6cuCrbKC_Ktn00UgD28nsT-4yZT1Oci3Fo9z=a6g@mail.gmail.com>
 <CAKgW=6+b7qmKr7qfTRRczBn7TYQ87HxcWjrOPhU0=HjK8W8vkQ@mail.gmail.com>
Message-ID: <CAK6Z60e1HtYpJOBs9qbwHkwF6fX3eVYCm0j_mJ-BD__5prN4VQ@mail.gmail.com>

> 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 <asmeurer at gmail.com> 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 <nico.schloemer at gmail.com> 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 at python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

From rossbar15 at gmail.com  Thu Sep 16 14:22:25 2021
From: rossbar15 at gmail.com (Ross Barnowski)
Date: Thu, 16 Sep 2021 13:22:25 -0500
Subject: [Numpy-discussion] npreadtext: `numpy.loadtxt` in C
Message-ID: <CADyYXuoQ_Yk5kbtPRe78nn8WkunDzGn+8PTSkc_kY3BWL_T=5A@mail.gmail.com>

Hi all,

This is to announce [`npreadtext`](https://github.com/BIDS-numpy/npreadtext),
a drop-in replacement for `numpy.loadtxt` written in C for improved
performance. We are now at feature parity with `loadtxt`, and would greatly
appreciate your feedback & testing. We hope eventually to include
`npreadtext` in NumPy itself.

## Installation

`npreadtext` has been tested with NumPy v1.18 and higher and can be
installed using:

```
python -m pip install numpy
python -m pip install git+git://github.com/BIDS-numpy/npreadtext
```

To enable the C-accelerated version of `np.loadtxt`, monkey-patch NumPy:

```python
>>> import numpy as np
>>> from npreadtxt import monkeypatch_numpy
```

This replaces `np.loadtxt` with `npreadtext._loadtxt`.

## Feedback

You may leave comments here or file issues on the [project issue tracker](
https://github.com/BIDS-numpy/npreadtext/issues). Please also share text
files that strain or break the reader.

## Benchmarks

Preliminary benchmarks show a significant improvement in performance:

```
python runtests.py --bench-compare monkeypatch-npreadtext bench_io

       npreadtext       np.loadtxt  speedup  function

+     7.74?0.04ms        146?0.8ms    18.85
 bench_io.LoadtxtCSVStructured.time_loadtxt_csv_struct_dtype
+      9.67?0.1ms        181?0.6ms    18.67
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int64', 100000)
+        969?10?s       17.9?0.1ms    18.48
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int64', 10000)
+         950?7?s      14.6?0.04ms    15.39
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int32', 10000)
+     9.65?0.03ms        146?0.2ms    15.13
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int32', 100000)
+     11.8?0.06ms        141?0.3ms    11.96
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float32', 100000)
+      11.9?0.1ms        141?0.3ms    11.88
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float64', 100000)
+      12.6?0.1ms        150?0.6ms    11.85
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('complex128', 100000)
+     1.18?0.01ms       13.9?0.1ms    11.74
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float64', 10000)
+     1.19?0.01ms      13.9?0.09ms    11.68
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float32', 10000)
+        1.27?0ms      14.7?0.06ms    11.64
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('complex128', 10000)
+     12.4?0.06ms        140?0.6ms    11.28
 bench_io.LoadtxtCSVComments.time_comment_loadtxt_csv(100000)
+     1.22?0.02ms      13.8?0.09ms    11.26
 bench_io.LoadtxtCSVComments.time_comment_loadtxt_csv(10000)
+      20.8?0.2?s        194?0.5?s     9.32
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int64', 100)
+      20.4?0.2?s        162?0.3?s     7.97
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int32', 100)
+        1.04?0ms      8.17?0.08ms     7.84
 bench_io.LoadtxtUseColsCSV.time_loadtxt_usecols_csv([1, 3, 5, 7])
+         884?2?s      6.79?0.02ms     7.68
 bench_io.LoadtxtUseColsCSV.time_loadtxt_usecols_csv([1, 3])
+     1.56?0.01ms      12.0?0.05ms     7.68
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('object', 10000)
+     16.1?0.05ms        122?0.3ms     7.56
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('object', 100000)
+     23.4?0.04?s        163?0.9?s     6.94
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('complex128', 100)
+     22.6?0.09?s        153?0.2?s     6.76
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float32', 100)
+      22.9?0.5?s        154?0.7?s     6.72
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float64', 100)
+      22.8?0.5?s        150?0.8?s     6.58
 bench_io.LoadtxtCSVComments.time_comment_loadtxt_csv(100)
+         809?8?s      5.10?0.02ms     6.30
 bench_io.LoadtxtUseColsCSV.time_loadtxt_usecols_csv(2)
+     7.31?0.01ms      42.0?0.08ms     5.75
 bench_io.LoadtxtCSVDateTime.time_loadtxt_csv_datetime(20000)
+         748?2?s      4.11?0.04ms     5.50
 bench_io.LoadtxtCSVDateTime.time_loadtxt_csv_datetime(2000)
+      26.0?0.2?s        131?0.3?s     5.02
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('object', 100)
+      87.3?0.4?s          436?1?s     5.00
 bench_io.LoadtxtCSVDateTime.time_loadtxt_csv_datetime(200)
+     2.09?0.01ms      10.1?0.04ms     4.86
 bench_io.LoadtxtReadUint64Integers.time_read_uint64(10000)
+        2.09?0ms      10.1?0.04ms     4.83
 bench_io.LoadtxtReadUint64Integers.time_read_uint64_neg_values(10000)
+       215?0.5?s         1.03?0ms     4.82
 bench_io.LoadtxtReadUint64Integers.time_read_uint64_neg_values(1000)
+       217?0.9?s         1.02?0ms     4.72
 bench_io.LoadtxtReadUint64Integers.time_read_uint64(1000)
+       123?0.6?s          580?3?s     4.71
 bench_io.LoadtxtReadUint64Integers.time_read_uint64_neg_values(550)
+       124?0.8?s          573?4?s     4.63
 bench_io.LoadtxtReadUint64Integers.time_read_uint64(550)
+     4.15?0.01ms      14.4?0.05ms     3.46
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('str', 10000)
+      58.6?0.1ms        195?0.8ms     3.33
 bench_io.LoadtxtCSVSkipRows.time_skiprows_csv(10000)
+      41.8?0.1ms          139?1ms     3.33
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('str', 100000)
+     64.6?0.09ms          215?1ms     3.32
 bench_io.LoadtxtCSVSkipRows.time_skiprows_csv(500)
+      64.9?0.2ms          215?2ms     3.30
 bench_io.LoadtxtCSVSkipRows.time_skiprows_csv(0)
+      55.0?0.5?s        154?0.4?s     2.81
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('str', 100)
+      23.9?0.1?s         60.1?1?s     2.51
 bench_io.LoadtxtCSVDateTime.time_loadtxt_csv_datetime(20)
+      12.1?0.2?s       29.4?0.2?s     2.44
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int64', 10)
+     12.0?0.05?s       26.2?0.2?s     2.18
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int32', 10)
+     12.5?0.08?s      26.1?0.09?s     2.08
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('complex128', 10)
+     12.3?0.04?s       24.9?0.4?s     2.02
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float64', 10)
+      12.3?0.1?s       24.8?0.2?s     2.02
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float32', 10)
+     12.2?0.04?s       24.5?0.1?s     2.01
 bench_io.LoadtxtCSVComments.time_comment_loadtxt_csv(10)
+      13.3?0.1?s       23.4?0.1?s     1.76
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('object', 10)
+      18.5?0.3?s       25.6?0.5?s     1.39
 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('str', 10)
```

The repository includes  [procedures for running benchmarks locally](
https://github.com/BIDS-numpy/npreadtext#benchmarking).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210916/e4b8ab69/attachment.html>