Re: [Numpy-discussion] NumPy Feature Request: Function to wrap angles to range [ 0, 2*pi] or [ -pi, pi ]

On Tue, Nov 24, 2020 at 6:38 AM Daniele Nicolodi wrote: > On 24/11/2020 10:25, Thomas wrote: > > Like Nathaniel said, it would not improve much when compared to the > > modulo operator. > > > > It could handle the edge cases better, but really the biggest benefit > > would be that it is more conv

[Numpy-discussion] NumPy Community Meeting Wednesday -- One our earlier from now on!

Hi all, There will be a NumPy Community meeting Wednesday November 25th at 12pm Pacific Time (19: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 signature.asc

Re: [Numpy-discussion] NumPy Feature Request: Function to wrap angles to range [ 0, 2*pi] or [ -pi, pi ]

I use my own implementation of the wrap function in kinematics and kinetics (robotics). Solutions beyond [0, 2pi] or [-pi, pi] can cause some problems when combined with learning algorithms, so we wrap them. Interestingly, today I reviewed code for a teammate. He had the exact same problem, but di

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Is there some community interest to develop fusion based high-performance array programming? Something like https://github.com/AccelerateHS/accelerate#an-embedded-language-for-accelerated-array-computations

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

This always seems like such a ridiculous argument. If CO2 emissions are directly proportional to the time it takes for a program to run, then there's no real need to concern ourselves with it. People already have a direct reason to avoid programs that take a long time to run, namely, that they take

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

On 11/24/2020 2:06 PM, Charles R Harris wrote: There are still ozone holes over the Antarctic, last time I looked they were explained as due to an influx of cold air. I believe industrial CFC usage, which has fallen since the Montreal Protocol, is still considered the primary culprit in ozone

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

On Tue, Nov 24, 2020 at 12:28 PM Benjamin Root wrote: > Digressing here, but the ozone hole over the antarctic was always going to > take time to recover because of the approximately 50 year residence time of > the CFCs in the upper atmosphere. Cold temperatures can actually speed up > depletion

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Digressing here, but the ozone hole over the antarctic was always going to take time to recover because of the approximately 50 year residence time of the CFCs in the upper atmosphere. Cold temperatures can actually speed up depletion because of certain ice crystal formations that give a boost in t

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

On Tue, Nov 24, 2020 at 11:54 AM Benjamin Root wrote: > > Given that AWS and Azure have both made commitments to have their data > centers be carbon neutral, and given that electricity and heat production > make up ~25% of GHG pollution, I find these sorts of > power-usage-analysis-for-the-sake-o

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Given that AWS and Azure have both made commitments to have their data centers be carbon neutral, and given that electricity and heat production make up ~25% of GHG pollution, I find these sorts of power-usage-analysis-for-the-sake-of-the-environment to be a bit disingenuous. Especially since GHG p

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Measuring running time of a program in arbitrary programming language is not an objective metric. Otherwise force everyone code in Assembler and we would be done as quick as possible. Hire 5 people to come to the workplace for 6 months to optimize it and we will be done with their transportation. T

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Hello, We’re trying to do a part of this in the TACO team, and with a Python wrapper in the form of PyData/Sparse. It will allow an abstract array/scheduling to take place, but there are a bunch of constraints, the most important one being that a C compiler cannot be required at runtime. Howev

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

On Tue, 2020-11-24 at 18:41 +0100, Jerome Kieffer wrote: > Hi Pierre, > > I agree with your point of view: the author wants to demonstrate C++ > and Fortran are better than Python... and environmentally speaking he > has some evidences. > > We develop with Python, Cython, Numpy, and OpenCL and wh

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Hi Pierre, I agree with your point of view: the author wants to demonstrate C++ and Fortran are better than Python... and environmentally speaking he has some evidences. We develop with Python, Cython, Numpy, and OpenCL and what annoys me most is the compilation time needed for the development of

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

I think we, the community, does have to take it seriously. NumPy and the rest of the ecosystem is trying to raise money to hire developers. This sentiment, which is much wider than a single paper, is a prevalent roadblock. -- Andy On Tue, Nov 24, 2020 at 11:12 AM Ilhan Polat wrote: > Do we have

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

On Tue, 2020-11-24 at 16:47 +0100, PIERRE AUGIER wrote: > Hi, > > I recently took a bit of time to study the comment "The ecological > impact of high-performance computing in astrophysics" published in > Nature Astronomy (Zwart, 2020, > https://www.nature.com/articles/s41550-020-1208-y, > https:

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Do we have to take it seriously to start with? Because, with absolutely no offense meant, I am having significant difficulty doing so. On Tue, Nov 24, 2020 at 4:58 PM PIERRE AUGIER < pierre.aug...@univ-grenoble-alpes.fr> wrote: > Hi, > > I recently took a bit of time to study the comment "The eco

[Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Hi, I recently took a bit of time to study the comment "The ecological impact of high-performance computing in astrophysics" published in Nature Astronomy (Zwart, 2020, https://www.nature.com/articles/s41550-020-1208-y, https://arxiv.org/pdf/2009.11295.pdf), where it is stated that "Best howeve

Re: [Numpy-discussion] NumPy Feature Request: Function to wrap angles to range [ 0, 2*pi] or [ -pi, pi ]

On Tue, Nov 24, 2020 at 11:37 AM Daniele Nicolodi wrote: > On 24/11/2020 10:25, Thomas wrote: > > Like Nathaniel said, it would not improve much when compared to the > > modulo operator. > > > > It could handle the edge cases better, but really the biggest benefit > > would be that it is more con

[Numpy-discussion] Added Rivest-Floyd selection algorithm as an option to numpy.partition

Hello everyone! I've implemented the Rivest-Floyd selection algorithm as a second option to the partition method. I found it works about 1.5 times faster on average for big array sizes; here are average times for finding a median:array length  10 introselect 4.6e-05 rivest_floyd 4.4e-05 array leng

Re: [Numpy-discussion] NumPy Feature Request: Function to wrap angles to range [ 0, 2*pi] or [ -pi, pi ]

On 24/11/2020 10:25, Thomas wrote: > Like Nathaniel said, it would not improve much when compared to the > modulo operator.  > > It could handle the edge cases better, but really the biggest benefit > would be that it is more convenient. Which edge cases? Better how? > And as the "unwrap" functi

Re: [Numpy-discussion] NumPy Feature Request: Function to wrap angles to range [ 0, 2*pi] or [ -pi, pi ]

Like Nathaniel said, it would not improve much when compared to the modulo operator. It could handle the edge cases better, but really the biggest benefit would be that it is more convenient. And as the "unwrap" function already exists, people would expect that and look for a function for the inv

Re: [Numpy-discussion] NumPy Feature Request: Function to wrap angles to range [ 0, 2*pi] or [ -pi, pi ]

On 24/11/2020 02:49, Nathaniel Smith wrote: > How would this proposed function compare to using the modulo operator, > like 'arr % (2*pi)'? I wrote almost the same word bu word reply, before realizing that taking the modulo looses the sign. The correct operation is slightly more complex (untested)