Mailman 3 July 2020 - NumPy-Discussion

Re: [Numpy-discussion] Help us to make NumPy better
by Inessa Pawson July 3, 2020

July 3, 2020

On Fri, Jul 3, 2020 at 5:45 PM <numpy-discussion-request(a)python.org> wrote: > > ---------- Forwarded message ---------- > From: Inessa Pawson <albuscode(a)gmail.com> > To: numpy-discussion(a)python.org > Cc: > Bcc: > Date: Fri, 3 Jul 2020 12:12:00 +1000 > Subject: [Numpy-discussion] Help us to make NumPy better > > Yes, it’s a survey. But it’s very important. > > Having limited human and financial resources is a common challenge for > open source projects. NumPy is not an exception. Please join this > structured dialogue with the NumPy leadership team to better guide and > prioritize decision-making about the development of NumPy as software and a > community. > > What started as a humble project by a dedicated core of user-developers > has since transformed into a foundational component of the widely-adopted > scientific Python ecosystem used by millions worldwide. To engage > non-English speaking stakeholders, the inaugural NumPy community survey is > offered in 7 additional languages: Bangla, Hindi, Japanese, Mandarin, > Portuguese, Russian, and Spanish. > > The survey will take about 15 minutes of your time and close on July 17th. Click > here <https://umdsurvey.umd.edu/jfe/form/SV_8bJrXjbhXf7saAl> to get > started. > > Inessa Pawson > > NumPy Survey Team > Thank you to everyone who took the time to participate in the inaugural NumPy community survey in the first 24 hours! It is an effort of a group of volunteers who showed a remarkable dedication to the project amidst the COVID-19 pandemic. I’d like to take this opportunity to acknowledge everyone involved. Survey team (in alphabetical order) Ross Barnowski Sebastian Berg Xiaoyi Deng Ralf Gommers Stephanie Mendoza Inessa Pawson Translations team (in alphabetical order) Yuki Dunn Kiko Correoso Garcia Jose Guzman Paul Ivanov Siddhartha Kapoor Tetsuo Koyama Guilherme Leobas Dayane Machado Mahfuza Humayra Mohona Aerik Pawson Zijie Poh Sumera Priyadarsini Shaloo Shalini Kriti Singh Alexandre de Siqueira Special thanks Prof. Frederick Conrad (Survey Research Center, Institute for Social Research, University of Michigan) Prof. Jim Lepkowski (Survey Research Center, Institute for Social Research, University of Michigan) Prof. Michael Traugott (Survey Research Center, Institute for Social Research, University of Michigan) Deji Suolang Mame Fatou Thiam -- Every good wish, *Inessa Pawson* Albus Code inessa(a)albuscode.org

1 0

Re: [Numpy-discussion] Google Summer of Docs Faq and Tutorial Proposed Structure .
by Saber Tooth July 3, 2020

July 3, 2020

Hi Melissa , I have been trying to follow https://numpy.org/devdocs/dev/index.html and build docs , i am not able to execute the building albeit following the exact guidelines. Is there a slack channel for this as i'd be able to better explain / resolve it there , till then : I have tried make html command after adhering to the above link Error when i haven't switched it to required git version : installed numpy 32f514f546 != current repo git version '3cf4c28906' use "make dist" or "GITVER=32f514f546 make html ..." Makefile:93: recipe for target 'version-check' failed make: *** [version-check] Error 1 Now when i make it work as per my installed numpy version : There are quite a lot of warnings and many problems like : document isn't included in any toctree failed to import 'numpy.polynomial.set_default_printstyle': no module named numpy.polynomial.set_default_printstyle WARNING: autodoc: failed to import module 'typing' from module 'numpy'; the following exception was raised: No module named 'numpy.typing' Many modules were missing which gave a warning , Now maybe the errors are coming in just my workspace , but I have tried reinstalling everything , got the latest version of cython too . It would be really helpful for me if you are able to give me some advice , or a workaround for the problem On Fri, 26 Jun 2020 at 01:39, Melissa Mendonça <melissawm(a)gmail.com> wrote: > Hello Mrinal, > > I don't think I have any other specific issues to comment on your > proposal. The mentors will analyze all proposals after July 9th. > > If you want to start contributing to the docs, you are welcome. You can > check the Contributor Guide (https://numpy.org/devdocs/dev/index.html), > How to contribute documentation ( > https://numpy.org/devdocs/dev/howto-docs.html) and the current > documentation. > > Thanks, > > Melissa > > On Thu, Jun 25, 2020 at 2:27 PM Saber Tooth <sabertooth2022(a)gmail.com> > wrote: > >> Hello Melissa , >> I have altered and built upon my previous proposal , if you could take a >> few minutes to read it it would be great . I have tried to explain the >> sections we had discussed in the meeting on 22 June . >> >> Moreover as per your feedback , I would like to start contributing to the >> docs and start building the docs in my Linux environment . >> >> Best , >> Mrinal Tyagi >> >> >> On Wed, 24 Jun 2020 at 2:36 PM, Saber Tooth <sabertooth2022(a)gmail.com> >> wrote: >> >>> Hello Melissa and all the Mentors , >>> >>> In the last meeting of NumPy Docs held on June 22nd , I had Proposed >>> Tutorial and Faqs structure , where it was discussed how we should include >>> them in the new structured Documentation . >>> Now after a lot of Googling I have been able to provide a >>> structured solution >>> It is very important for us to include the FAQs section , but why ? >>> If we see how many views some questions on Stack overflow >>> https://stackoverflow.com/questions/tagged/numpy?tab=frequent&page=1&pagesi… >>> have got the answer is obvious , the 1st page itself has garnered some 4-5 *million >>> *views and there are really many questions . It means if we are able to >>> answer some of these questions ,not necessarily the exact questions , it >>> would be really good for the Docs . >>> >>> I have tried to break the FAQs page into sections so that everything is >>> not cramped onto one page and we have good docs as per SEO guidelines . >>> I have structured based on best practices for the FAQs section : >>> https://www.shivarweb.com/9665/faq-page-best-practices/ . >>> >>> I have improved further upon my previous proposal , please have a look. >>> Eagerly waiting @Melissa Mendonça <melissawm(a)gmail.com> @Ralf Gommers >>> <ralf.gommers(a)gmail.com> for your feedback on the same , I would be >>> obliged if you have some ideas which could be incorporated with the same or >>> built upon these . >>> >>> >>> >>> Link to Proposal : >>> https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_H… >>> >>> >>> Link to FAQs Proposed structure : >>> https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_H… >>> >>> Link to Tutorials Proposed structure : >>> https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_H… >>> >>> Thanks , >>> Mrinal Tyagi >>> >>

2 2

Re: [Numpy-discussion] Python for Climate Action session at SciPy'20
by Inessa Pawson July 3, 2020

July 3, 2020

Juan, I’ve scheduled the “Python for Climate Action” session for July 8th at 5 - 6 p.m. CDT. Mark, it would be great if someone from pvlib could moderate it. The networking sessions at SciPy'20 will be hosted in a format similar to unconferences. We will be using Zoom to make it easier for the moderators to oversee their sessions. Don't hesitate to contact me if you have any further questions regarding this session. ---------- Forwarded message ---------- > From: "Dr. Mark Alexander Mikofski PhD" <mikofski(a)berkeley.edu> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Thu, 2 Jul 2020 09:09:32 -0700 > Subject: Re: [Numpy-discussion] Python for Climate Action session at > SciPy'20 > I can repost this on pvlib (solar energy photovoltaic library) Python > Google group (https://groups.google.com/forum/m/#!forum/pvlib-python). We > have plenty of both climate and atmospheric scientists, and we are avid > users of Numpy, SciPy, and the scientific stack. We would love to share > constructive uses of Python in climate science. > > On Thu, Jul 2, 2020, 7:18 AM Juan Nunez-Iglesias <jni(a)fastmail.com> wrote: > >> Hi Inessa, >> >> Thanks for offering! I definitely want to participate but I would *love >> it* if an actual climate scientist or even *any* atmospheric scientist >> would step up to chair the session! I have not thought all that deeply >> about this problem, and mostly I feel helpless and frustrated. >> >> If no one else volunteers though I'm happy to do it. >> >> I much prefer the Wednesday session. Let's book it in! >> >> Thank you all, >> >> Juan. >> >> On 2 Jul 2020, at 8:38 pm, Inessa Pawson <albuscode(a)gmail.com> wrote: >> >> Hi, Juan! >> I’m still in the process of scheduling live networking sessions at >> SciPy’20 and would be happy to set up one on the topic of Python for >> Climate Action. We could host it on July 8th or 10th at 5 - 6 p.m. CDT. >> Would you be available to moderate it? >> >> -- Every good wish, *Inessa Pawson* Albus Code inessa(a)albuscode.org

1 0

Proposal to add clause to license prohibiting use by oil and gas extraction companies
by John Preston July 2, 2020

July 2, 2020

Hello all, The following proposal was originally issue #16722 on GitHub but at the request of Matti Picus I am moving the discussion to this list. "NumPy is the fundamental package needed for scientific computing with Python." I am asking the NumPy project to leverage its position as a core dependency among statistical, numerical, and ML projects, in the pursuit of climate justice. It is easy to identify open-source software used by the oil and gas industry which relies on NumPy [1] [2] , and it is highly likely that NumPy is used in closed-source and in-house software at oil and gas extraction companies such as Aramco, ExxonMobil, BP, Shell, and others. I believe it is possible to use software licensing to discourage the use of NumPy and dependent packages by companies such as these, and that doing so would frustrate the ability of these companies to identify and extract new oil and gas reserves. I propose NumPy's current BSD 3-Clause license be extended to include the following conditions, in line with the Climate Strike License [3] : * The Software may not be used in applications and services that are used for or aid in the exploration, extraction, refinement, processing, or transportation of fossil fuels. * The Software may not be used by companies that rely on fossil fuel extraction as their primary means of revenue. This includes but is not limited to the companies listed at https://climatestrike.software/blocklist I accept that there are issues around adopting such a proposal, including that: addition of such clauses violates the Open Source Initiative's canonical Open Source Definition, which explicitly excludes licenses that limit re-use "in a specific field of endeavor", and therefore if these clauses were adopted NumPy would no longer "be open-source" by this definition; there may be collateral damage among the wider user base and project sponsorship, due to the vague nature of the first clause, and this may affect the longevity of the project and its standing within the Python, numerical, statistical, and ML communities. My intention with the opening of this issue is to promote constructive discussion of the use of software licensing -- and other measures -- for working towards climate justice -- and other forms of justice -- in the context of NumPy and other popular open-source libraries. Some people will say that NumPy is "just a tool" and that it sits independent of how it is used, but due to its utility and its influence as a major open-source library, I think it is essential that we consider the position of the Climate Strike License authors, that "as tech workers, we should take responsibility in how our software is used". Many thanks to all of the contributors who have put so much time and energy into NumPy. ✨ ❤️ 😃 [1] https://github.com/gazprom-neft/petroflow [2] https://github.com/climate-strike/analysis [3] https://github.com/climate-strike/license

12 12

Help us to make NumPy better
by Inessa Pawson July 2, 2020

July 2, 2020

Yes, it’s a survey. But it’s very important. Having limited human and financial resources is a common challenge for open source projects. NumPy is not an exception. Please join this structured dialogue with the NumPy leadership team to better guide and prioritize decision-making about the development of NumPy as software and a community. What started as a humble project by a dedicated core of user-developers has since transformed into a foundational component of the widely-adopted scientific Python ecosystem used by millions worldwide. To engage non-English speaking stakeholders, the inaugural NumPy community survey is offered in 7 additional languages: Bangla, Hindi, Japanese, Mandarin, Portuguese, Russian, and Spanish. The survey will take about 15 minutes of your time and close on July 17th. Click here <https://umdsurvey.umd.edu/jfe/form/SV_8bJrXjbhXf7saAl> to get started. Inessa Pawson NumPy Survey Team

1 0

Improving Complex Comparison/Ordering in Numpy
by Rakesh Vasudevan July 2, 2020

July 2, 2020

Hi all, As a follow up to gh-15981 <https://github.com/numpy/numpy/issues/15981>, I would like to propose a change to bring complex dtype(s) comparison operators and related functions, in line with respective cpython implementations. The current state of complex dtype comparisons/ordering as summarised in the issue is as follows: # In python >> cnum = 1 + 2j >> cnum_two = 1 + 3j # Doing a comparision yields >> cnum > cnum_two TypeError: '>' not supported between instances of 'complex' and 'complex' # Doing the same in Numpy scalar comparision >> np.array(cnum) > np.array(cnum_two) # Yields False *NOTE*: only >, <, >= , <= do not work on complex numbers in python , equality (==) does work similarly sorting uses comparison operators behind to sort complex values. Again this behavior diverges from the default python behavior. # In native python >> clist = [cnum, cnum_2] >> sorted(clist, key=lambda c: (c.real, c.imag)) [(1+2j), (1+3j)] # In numpy >> np.sort(clist) #Uses the default comparision order # Yields same result # To get a cpython like sorting call we can do the following in numpy np.take_along_axis(clist, np.lexsort((clist.real, clist.imag), 0), 0) This proposal aims to bring parity between default python handling of complex numbers and handling complex types in numpy This is a two-step process 1. Sort complex numbers in a pythonic way , accepting key arguments, and deprecate usage of sort() on complex numbers without key argument 1. Possibly extend this to max(), min(), if it makes sense to do so. 2. Since sort() is being updated for complex numbers, searchsorted() is also a good candidate for implementing this change. 2. Once this is done, we can deprecate the usage of comparison operators (>, <, >= , <=) on complex dtypes *Handling sort() for complex numbers* There are two approaches we can take for this 1. update sort() method, to have a ‘key’ kwarg. When key value is passed, use lexsort to get indices and continue sorting of it. We could support lambda function keys like python, but that is likely to be very slow. 2. Create a new wrapper function sort_by() (placeholder name, Requesting name suggestions/feedback)That essentially acts like a syntactic sugar for 1. np.take_along_axis(clist, np.lexsort((clist.real, clist.imag), 0), 0) 1. Improve the existing sort_complex() method with the new key search functionality (Though the change will only reflect for complex dtypes). We could choose either method, both have pros and cons , approach 1 makes the sort function signature, closer to its python counterpart, while using approach 2 provides a better distinction between the two approaches for sorting. The performance on approach 1 function would vary, due to the key being an optional argument. Would love the community’s thoughts on this. *Handling min() and max() for complex numbers* Since min and max are essentially a set of comparisons, in python they are not allowed on complex numbers >> clist = [cnum, cnum_2] >>> min(clist) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: '<' not supported between instances of 'complex' and 'complex' # But using keys argument again works min(clist, key=lambda c: (c.real, c.imag)) We could use a similar key kwarg for min() and max() in python, but question remains how we handle the keys, in this use case , naive way would be to sort() on keys and take last or first element, which is likely going to be slow. Requesting suggestions on approaching this. *Comments on isclose()* Both python and numpy use the absolute value/magnitude for comparing if two values are close enough. Hence I do not see this change affecting this function. Requesting feedback and suggestions on the above. Thank you, Rakesh

4 6

Re: [Numpy-discussion] Python for Climate Action session at SciPy'20
by Inessa Pawson July 2, 2020

July 2, 2020

Hi, Juan! I’m still in the process of scheduling live networking sessions at SciPy’20 and would be happy to set up one on the topic of Python for Climate Action. We could host it on July 8th or 10th at 5 - 6 p.m. CDT. Would you be available to moderate it? > ---------- Forwarded message ---------- > From: Juan Nunez-Iglesias <jni(a)fastmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Thu, 2 Jul 2020 18:58:11 +1000 > Subject: Re: [Numpy-discussion] Proposal to add clause to license > prohibiting use by oil and gas extraction companies > Hi everyone, > > If you live in Australia, this has been a rough year to think about > climate change. After the hottest and driest year on record, over 20% of > the forest surface area of the south east was burned in the bushfires. > Although I was hundreds of kilometres from the nearest fire, the air > quality was rated as hazardous for several days in my city. This brought > home for me two points. > > One, that "4ºC" is not about taking off a jumper and going to the beach > more often, but actually represents a complete transformation of our > planet. 4ºC is what separates us from the last ice age, so we can expect > our planet in 80 years to be as unrecognisable from today as today is from > the ice age. > > Two, that climate change is already with us, and we can't just continue to > ignore the problem and enjoy whatever years of climate peace we thought we > had left. Greta has it right, we are running out of time and absolutely > drastic action is needed. > > All this is a prelude to add my voice to everyone who has already said > that *messing with the NumPy license is absolutely *not* the drastic > action needed*, and will be counter-productive, as many have noted. > > Having said this, I'm happy that the community is getting involved and > getting active and coming up with creative ideas to do their part. If > someone wants to start a "Pythonistas for Climate Action" user group, I'll > be the first to join. I had planned to give a lightning talk in the vein of > the above at SciPy, which, and believe me that I hate to hate on my > favourite conference, recently loudly thanked Shell [1] for being a > platinum sponsor. (Not to mention that Enthought derives about a third of > its income from fossil fuel companies.) Unfortunately and for obvious > reasons I won't make it to SciPy after all, but again, I'm happy to see the > community rising. > > Perhaps this is derailing the discussion, but, anyone up for a "Python for > Climate Action" BoF at the conference? I can probably make the > late-afternoon BoFs given the time difference. > > Juan. > > [1]: https://twitter.com/SciPyConf/status/1276898138977193984 > > > -- Every good wish, *Inessa Pawson* Albus Code inessa(a)albuscode.org

3 2