NumPy-Discussion May 2020

numpy-discussion@python.org

44 participants
45 discussions

by Daniel Davies

Is clock-throttling of interest here? It would be really annoying if the code that chooses a macro implementation has to guess how much power will be consumed by each core. Or has to dynamically pick a macro implementation based on the current frequencies of all the cores. https://lemire.me/blog/2018/08/13/the-dangers-of-avx-512-throttling-myth-or… https://lemire.me/blog/2018/09/07/avx-512-when-and-how-to-use-these-new-ins… Dan

1 year, 8 months

NumPy Community Meeting Wednesday

by Sebastian Berg

Hi all, There will be a NumPy Community meeting Wednesday May 13th at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 year, 8 months

Reg: GSoD 2020

by PRUBHTEJ SINGH

Greetings I would like to contribute to numpy's documentation under GSoD-2020 program. Requesting your guidance for the same. Regards Prubhtej Singh

1 year, 8 months

GSoD 2020!

by Ben Nathanson

Congratulations on getting chosen once again for Season of Docs! I'm very eager to talk about collaborating.

1 year, 8 months

Update the Code of Conduct Committee Membership (new members wanted)

by Sebastian Berg

Hi all, it has come up in the last community call that many of our committee membership lists have not been updated in a while. This is not a big issue as such. But, while these committees are not very active on a day-to-day basis, they are an important part of the community and it is better to update them regularly and thus also ensure they remain representative of the community. We would like to start by updating the members of the Code of Conduct (CoC) committee. The CoC committee is in charge of responding and following up to any reports of CoC breaches, as stated in: https://docs.scipy.org/doc/numpy/dev/conduct/code_of_conduct.html#incident-… If you are interested in or happy to serve on our CoC committee please let me or e.g. Ralf Gommers know, join the next community meeting (April 29th, 11:00PDT/18:00UTC), or reply on the list. I hope we will be able to discuss and reach a consensus between those interested and involved quickly (possibly already on the next community call). In either case, before any changes they will be run by the mailing list to ensure community consensus. Cheers, Sebastian

1 year, 8 months

Feelings about type aliases in NumPy

by Joshua Wilson

Hey everyone, Over in numpy-stubs we've been working on typing "array like": https://github.com/numpy/numpy-stubs/pull/66 It would be nice if the type were public so that downstream projects could use it (e.g. it would be very helpful in SciPy). Originally the plan was to only make it publicly available at typing time and not runtime, which would mean that no changes to NumPy are necessary; see https://github.com/numpy/numpy-stubs/pull/66#issuecomment-618784833 for more information on how that works. But, Stephan pointed out that it might be confusing to users for objects to only exist at typing time, so we came around to the question of whether people are open to the idea of including the type aliases in NumPy itself. Ralf's concrete proposal was to make a module numpy.types (or maybe numpy.typing) to hold the aliases so that they don't pollute the top-level namespace. The module would initially contain the types - ArrayLike - DtypeLike - (maybe) ShapeLike Note that we would not need to make changes to NumPy right away; instead it would probably be done when numpy-stubs is merged into NumPy itself. What do people think? - Josh

1 year, 8 months

divmod(1.0, 0.0) bug

by Anirudh Subramanian

Hi all, There has been a discussion about divmod (1.0, 0.0) bug here : https://github.com/numpy/numpy/issues/14900 and https://github.com/numpy/numpy/pull/16161 . *SUMMARY* Currently divmod(1.0, 0.0) sets the "Invalid error" and returns (nan, nan). This is not consistent with IEEE 754 <https://en.wikipedia.org/wiki/IEEE_754> standard which says that 1.0/0.0 divisions should return inf and raise dividebyzero error. Although this may not apply to divmod, it should apply to floor_divide and mod. I have summarized in the table below, summarizing current state and expected state. Operator Warning message Expected warning Result Expected Result np.divmod Invalid error invalid and dividebyzero ?? nan, nan inf, nan np.fmod(1.0, 0.0) Invalid error Invalid nan nan np.floor_divide(1.0, 0.0) Invalid error Dividebyzero nan inf np.remainder(1.0, 0.0) Invalid error Invalid nan nan For remainder and fmod above, according to the standard, it is supposed to raise invalid error. We need to change the code to also raise dividebyzero error for floor_divide. The question is what to do for np.divmod (since this is not defined by standard). My opinion is in this case we need to set both dividebyzero and invalid error flags since its a combination of these two operations. *USER IMPACT* This is going to cause a breaking change/silent incorrect results to atleast some users who are either doing one or two of the following: 1. expecting nans from their output and check isnan but not isinf in their code and accordingly do further computations. 2. who currently call raise only on invalid and not dividebyzero errors for any of the above listed operations. Considering this we can try one of the two things: 1. Create a futurewarning for every divmod(1.0, 0.0) path. This may be very noisy and I cannot think of an action for a user to take to suppress this. 2. Since bug fixes are exempt from backwards compatibility policy <https://numpy.org/neps/nep-0023-backwards-compatibility.html> just notify in the release notes, maybe after a couple of releases. (More Impactful) *OTHER ISSUES?* Depending on the compiler, and if it implements annex F of the C standard, it may not support 1.0/0.0 operation and may crash. Also this is the case for true_divide also, so we wont be breaking more users than we currently are. Would like to hear your thoughts about this! Anirudh

1 year, 8 months

NumPy Development Meeting Tomorrow - Triage Focus

by Sebastian Berg

Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, May 6th) at 11 am Pacific Time (18: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 or simply discussed briefly. Just comment on it so we can label it, or add your PR/issue to this weeks topics for discussion. Best regards Sebastian

1 year, 8 months

Season of Docs technical writer

by Ben Nathanson

I've updated my page (https://bennathanson.com/numpy2020) to include a section on Curation and Adaptation.

1 year, 8 months

Re: [Numpy-discussion] Closing resolved good-first-issues

by Tina Oberoi

Fri, 1 May 2020 18:05:14 Ralf Gommers <ralf.gommers(a)gmail.com> wrote: > > Hi Tina, thanks for pointing that out. I have added you to the triage team, > so you are able to close issues that you already noticed are fixed. I'll > have a look at labelling some new ones now. These are the issues that have pull requests merged but still open, Please let me know if I am wrong else we can close these issues: - Issue #9476 <https://github.com/numpy/numpy/issues/9476> - Issue #2802 <https://github.com/numpy/numpy/issues/2802> - Issue #11875 <https://github.com/numpy/numpy/issues/11875> - Issue #13114 <https://github.com/numpy/numpy/issues/13114> - Issue #13758 <https://github.com/numpy/numpy/issues/13758> Thanks and Regards Tina

1 year, 8 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

NumPy-Discussion May 2020