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

[Daniele Nicolodi]

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):

def wrap(alpha):
return (alpha + np.pi) % 2.0 * np.pi - np.pi

However, I don't think there is much value in adding something so
trivial as a function to numpy: I cannot think to any commonly used
algorithm that requires wrapping the phase, and it is going to be an
infinite source of bikesheeding whether the wrapped range should be
[-pi, pi) or (-pi, pi] or (0, 2*pi] or [0, 2*pi)

Cheers,
Dan


> On Mon, Nov 23, 2020, 16:13 Thomas  > wrote:
> 
> Hi,
> 
> I have a proposal for a feature and I hope this is the right place
> to post this.
> 
> The idea is to have a function to map any input angle to the range
> of [ 0, 2*pi ] or [ - pi, pi ].
> 
> There already is a function called 'unwrap' that does the opposite,
> so I'd suggest calling this function 'wrap'.
> 
> Example usage:
> # wrap to range [ 0, 2*pi ]
> >>> np.wrap([ -2*pi, -pi, 0, 4*pi ])
> [0, pi, 0, 2*pi]
> 
> There is some ambiguity regarding what the solution should be for
> the extremes. An example would be an input of 4*pi, as both 0 and
> 2*pi would be valid mappings.
> 
> There has been interest for this topic in the community
> (see https://stackoverflow.com/questions/15927755/opposite-of-numpy-unwrap
> ).
> 
> Similar functions exist for Matlab
> (see https://de.mathworks.com/help/map/ref/wrapto2pi.html
> ). They solved
> the ambiguity by mapping "positive multiples of 2*pi map to 2*pi and
> negative multiples of 2*pi map to 0." for the 0 to 2*pi case.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org 
> https://mail.python.org/mailman/listinfo/numpy-discussion
> 
> 
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
> 

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

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

[Thomas]

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 inverse operation (at least I did).

On Tue, 24 Nov 2020 at 09:22, Daniele Nicolodi  wrote:

> 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):
>
> def wrap(alpha):
> return (alpha + np.pi) % 2.0 * np.pi - np.pi
>
> However, I don't think there is much value in adding something so
> trivial as a function to numpy: I cannot think to any commonly used
> algorithm that requires wrapping the phase, and it is going to be an
> infinite source of bikesheeding whether the wrapped range should be
> [-pi, pi) or (-pi, pi] or (0, 2*pi] or [0, 2*pi)
>
> Cheers,
> Dan
>
>
> > On Mon, Nov 23, 2020, 16:13 Thomas  > > wrote:
> >
> > Hi,
> >
> > I have a proposal for a feature and I hope this is the right place
> > to post this.
> >
> > The idea is to have a function to map any input angle to the range
> > of [ 0, 2*pi ] or [ - pi, pi ].
> >
> > There already is a function called 'unwrap' that does the opposite,
> > so I'd suggest calling this function 'wrap'.
> >
> > Example usage:
> > # wrap to range [ 0, 2*pi ]
> > >>> np.wrap([ -2*pi, -pi, 0, 4*pi ])
> > [0, pi, 0, 2*pi]
> >
> > There is some ambiguity regarding what the solution should be for
> > the extremes. An example would be an input of 4*pi, as both 0 and
> > 2*pi would be valid mappings.
> >
> > There has been interest for this topic in the community
> > (see
> https://stackoverflow.com/questions/15927755/opposite-of-numpy-unwrap
> > <
> https://stackoverflow.com/questions/15927755/opposite-of-numpy-unwrap>).
> >
> > Similar functions exist for Matlab
> > (see https://de.mathworks.com/help/map/ref/wrapto2pi.html
> > ). They solved
> > the ambiguity by mapping "positive multiples of 2*pi map to 2*pi and
> > negative multiples of 2*pi map to 0." for the 0 to 2*pi case.
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org 
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> > 
> >
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Daniele Nicolodi]

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" function already exists,

The unwrap() function exists because it is not as trivial.

> people would expect that
> and look for a function for the inverse operation (at least I did).

What is your use of a wrap() function? I cannot think of any.

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

[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 length  100 
introselect 5.5e-05
rivest_floyd 4.7e-05
array length  1000 
introselect 6.9e-05
rivest_floyd 6.5e-05
array length  1 
introselect 3.1e-04
rivest_floyd 2.3e-04
array length  10 
introselect 2.9e-03 
rivest_floyd 2.0e-03
array length  100 
introselect 2.9e-02
rivest_floyd 2.0e-02

I've created a pull request https://github.com/numpy/numpy/pull/17813 and implemented reviewer's suggestions and fixes. Do you think this feature should be added? I am new to open source, sorry if I am doing anything wrong.

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

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

[Ralf Gommers]

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 convenient.
>
> Which edge cases? Better how?
>
> > And as the "unwrap" function already exists,
>
> The unwrap() function exists because it is not as trivial.
>

I agree, we prefer not to add trivial functions like this. To help those
few people that may need this, maybe just add the one-liner Daniele gave to
the Notes section of unwrap()?

Cheers,
Ralf



> > people would expect that
> > and look for a function for the inverse operation (at least I did).
>
> What is your use of a wrap() function? I cannot think of any.
>
> Cheers,
> Dan
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[PIERRE AUGIER]

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 however, 
for the environment is to abandon Python for a more environmentally friendly 
(compiled) programming language.".

I wrote a simple Python-Numpy implementation of the problem used for this study 
(https://www.nbabel.org) and, accelerated by Transonic-Pythran, it's very 
efficient. Here are some numbers (elapsed times in s, smaller is better):

| # particles |  Py | C++ | Fortran | Julia |
|-|-|-|-|---|
| 1024|  29 |  55 |   41|   45  |
| 2048| 123 | 231 |  166|  173  |

The code and a modified figure are here: https://github.com/paugier/nbabel 
(There is no check on the results for https://www.nbabel.org, so one still has 
to be very careful.)

I think that the Numpy community should spend a bit of energy to show what can 
be done with the existing tools to get very high performance (and low CO2 
production) with Python. This work could be the basis of a serious reply to the 
comment by Zwart (2020).

Unfortunately the Python solution in https://www.nbabel.org is very bad in 
terms of performance (and therefore CO2 production). It is also true for most 
of the Python solutions for the Computer Language Benchmarks Game in 
https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes here 
https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else).

We could try to fix this so that people see that in many cases, it is not 
necessary to "abandon Python for a more environmentally friendly (compiled) 
programming language". One of the longest and hardest task would be to 
implement the different cases of the Computer Language Benchmarks Game in 
standard and modern Python-Numpy. Then, optimizing and accelerating such code 
should be doable and we should be able to get very good performance at least 
for some cases. Good news for this project, (i) the first point can be done by 
anyone with good knowledge in Python-Numpy (many potential workers), (ii) for 
some cases, there are already good Python implementations and (iii) the work 
can easily be parallelized.

It is not a criticism, but the (beautiful and very nice) new Numpy website 
https://numpy.org/ is not very convincing in terms of performance. It's written 
"Performant The core of NumPy is well-optimized C code. Enjoy the flexibility 
of Python with the speed of compiled code." It's true that the core of Numpy is 
well-optimized C code but to seriously compete with C++, Fortran or Julia in 
terms of numerical performance, one needs to use other tools to move the 
compiled-interpreted boundary outside the hot loops. So it could be reasonable 
to mention such tools (in particular Numba, Pythran, Cython and Transonic).

Is there already something planned to answer to Zwart (2020)?

Any opinions or suggestions on this potential project?

Pierre

PS: Of course, alternative Python interpreters (PyPy, GraalPython, Pyjion, 
Pyston, etc.) could also be used, especially if HPy 
(https://github.com/hpyproject/hpy) is successful (C core of Numpy written in 
HPy, Cython able to produce HPy code, etc.). However, I tend to be a bit 
skeptical in the ability of such technologies to reach very high performance 
for low-level Numpy code (performance that can be reached by replacing whole 
Python functions with optimized compiled code). Of course, I hope I'm wrong! 
IMHO, it does not remove the need for a successful HPy!

--
Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
BP53, 38041 Grenoble Cedex, Francetel:+33.4.56.52.86.16
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Ilhan Polat]

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 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
> however, for the environment is to abandon Python for a more
> environmentally friendly (compiled) programming language.".
>
> I wrote a simple Python-Numpy implementation of the problem used for this
> study (https://www.nbabel.org) and, accelerated by Transonic-Pythran,
> it's very efficient. Here are some numbers (elapsed times in s, smaller is
> better):
>
> | # particles |  Py | C++ | Fortran | Julia |
> |-|-|-|-|---|
> | 1024|  29 |  55 |   41|   45  |
> | 2048| 123 | 231 |  166|  173  |
>
> The code and a modified figure are here: https://github.com/paugier/nbabel
> (There is no check on the results for https://www.nbabel.org, so one
> still has to be very careful.)
>
> I think that the Numpy community should spend a bit of energy to show what
> can be done with the existing tools to get very high performance (and low
> CO2 production) with Python. This work could be the basis of a serious
> reply to the comment by Zwart (2020).
>
> Unfortunately the Python solution in https://www.nbabel.org is very bad
> in terms of performance (and therefore CO2 production). It is also true for
> most of the Python solutions for the Computer Language Benchmarks Game in
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes here
> https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else).
>
> We could try to fix this so that people see that in many cases, it is not
> necessary to "abandon Python for a more environmentally friendly (compiled)
> programming language". One of the longest and hardest task would be to
> implement the different cases of the Computer Language Benchmarks Game in
> standard and modern Python-Numpy. Then, optimizing and accelerating such
> code should be doable and we should be able to get very good performance at
> least for some cases. Good news for this project, (i) the first point can
> be done by anyone with good knowledge in Python-Numpy (many potential
> workers), (ii) for some cases, there are already good Python
> implementations and (iii) the work can easily be parallelized.
>
> It is not a criticism, but the (beautiful and very nice) new Numpy website
> https://numpy.org/ is not very convincing in terms of performance. It's
> written "Performant The core of NumPy is well-optimized C code. Enjoy the
> flexibility of Python with the speed of compiled code." It's true that the
> core of Numpy is well-optimized C code but to seriously compete with C++,
> Fortran or Julia in terms of numerical performance, one needs to use other
> tools to move the compiled-interpreted boundary outside the hot loops. So
> it could be reasonable to mention such tools (in particular Numba, Pythran,
> Cython and Transonic).
>
> Is there already something planned to answer to Zwart (2020)?
>
> Any opinions or suggestions on this potential project?
>
> Pierre
>
> PS: Of course, alternative Python interpreters (PyPy, GraalPython, Pyjion,
> Pyston, etc.) could also be used, especially if HPy (
> https://github.com/hpyproject/hpy) is successful (C core of Numpy written
> in HPy, Cython able to produce HPy code, etc.). However, I tend to be a bit
> skeptical in the ability of such technologies to reach very high
> performance for low-level Numpy code (performance that can be reached by
> replacing whole Python functions with optimized compiled code). Of course,
> I hope I'm wrong! IMHO, it does not remove the need for a successful HPy!
>
> --
> Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr
> LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
> BP53, 38041 Grenoble Cedex, Francetel:+33.4.56.52.86.16
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Sebastian Berg]

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://arxiv.org/pdf/2009.11295.pdf), where it is stated that "Best
> however, for the environment is to abandon Python for a more
> environmentally friendly (compiled) programming language.".
> 
> I wrote a simple Python-Numpy implementation of the problem used for
> this study (https://www.nbabel.org) and, accelerated by Transonic-
> Pythran, it's very efficient. Here are some numbers (elapsed times in
> s, smaller is better):
> 
> > # particles |  Py | C++ | Fortran | Julia |
> > -|-|-|-|---|
> > 1024|  29 |  55 |   41|   45  |
> > 2048| 123 | 231 |  166|  173  |
> 
> The code and a modified figure are here: 
> https://github.com/paugier/nbabel (There is no check on the results
> for https://www.nbabel.org, so one still has to be very careful.)
> 
> I think that the Numpy community should spend a bit of energy to show
> what can be done with the existing tools to get very high performance
> (and low CO2 production) with Python. This work could be the basis of
> a serious reply to the comment by Zwart (2020).
> 
> Unfortunately the Python solution in https://www.nbabel.org is very
> bad in terms of performance (and therefore CO2 production). It is
> also true for most of the Python solutions for the Computer Language
> Benchmarks Game in 
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes
> here 
> https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else
> ).
> 
> We could try to fix this so that people see that in many cases, it is
> not necessary to "abandon Python for a more environmentally friendly
> (compiled) programming language". One of the longest and hardest task
> would be to implement the different cases of the Computer Language
> Benchmarks Game in standard and modern Python-Numpy. Then, optimizing
> and accelerating such code should be doable and we should be able to
> get very good performance at least for some cases. Good news for this
> project, (i) the first point can be done by anyone with good
> knowledge in Python-Numpy (many potential workers), (ii) for some
> cases, there are already good Python implementations and (iii) the
> work can easily be parallelized.
> 
> It is not a criticism, but the (beautiful and very nice) new Numpy
> website https://numpy.org/ is not very convincing in terms of
> performance. It's written "Performant The core of NumPy is well-
> optimized C code. Enjoy the flexibility of Python with the speed of
> compiled code." It's true that the core of Numpy is well-optimized C
> code but to seriously compete with C++, Fortran or Julia in terms of
> numerical performance, one needs to use other tools to move the
> compiled-interpreted boundary outside the hot loops. So it could be
> reasonable to mention such tools (in particular Numba, Pythran,
> Cython and Transonic).
> 
> Is there already something planned to answer to Zwart (2020)?

I don't think there is any need for rebuttal. The author is right
right, you should not write the core of an N-Body simulation in Python
:).  I completely disagree with the focus on programming
languages/tooling, quite honestly.


A PhD who writes performance critical code, must get the education
necessary to do it well.  That may mean learning something beyond
Python, but not replacing Python entirely.

In one point the opinion notes:

NumPy, for example, is mostly used for its advanced array handling
and support functions. Using these will reduce runtime and,
therefore, also carbon emission, but optimization is generally 
stopped as soon as the calculation runs within an unconsciously
determined reasonable amount of time, such as the coffee-refill
timescale or a holiday weekend.

IMO, this applies to any other programming language just as much.  If
your correlation is fast enough, you will not invest time in
implementing an fft based algorithm.  If you iterate your array in
Fortran instead of C-order in your C++ program (which new users may
just do randomly), you are likely to waste more(!) cpu cycles then if
you were using NumPy :).
Personally, I am always curious how much of that "GPUs are faster"
factor is actually due to the effort spend on making it faster...


My angle is that in the end, it is far more about technical knowledge
than about using the "right" language.

An example: At an old workplace we had had some simulations running
five times slower, because years earlier someone forgot to set
`RELEASE=True` in the default config, always compiling in debug mode!

But honestly, if it was 5 times faster, we probably would probably have
done at least 3 times as many simulations :).
Aside from that, most complex C/C++ program

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

[Andy Ray Terrel]

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 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 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
>> however, for the environment is to abandon Python for a more
>> environmentally friendly (compiled) programming language.".
>>
>> I wrote a simple Python-Numpy implementation of the problem used for this
>> study (https://www.nbabel.org) and, accelerated by Transonic-Pythran,
>> it's very efficient. Here are some numbers (elapsed times in s, smaller is
>> better):
>>
>> | # particles |  Py | C++ | Fortran | Julia |
>> |-|-|-|-|---|
>> | 1024|  29 |  55 |   41|   45  |
>> | 2048| 123 | 231 |  166|  173  |
>>
>> The code and a modified figure are here:
>> https://github.com/paugier/nbabel (There is no check on the results for
>> https://www.nbabel.org, so one still has to be very careful.)
>>
>> I think that the Numpy community should spend a bit of energy to show
>> what can be done with the existing tools to get very high performance (and
>> low CO2 production) with Python. This work could be the basis of a serious
>> reply to the comment by Zwart (2020).
>>
>> Unfortunately the Python solution in https://www.nbabel.org is very bad
>> in terms of performance (and therefore CO2 production). It is also true for
>> most of the Python solutions for the Computer Language Benchmarks Game in
>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes here
>> https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else).
>>
>> We could try to fix this so that people see that in many cases, it is not
>> necessary to "abandon Python for a more environmentally friendly (compiled)
>> programming language". One of the longest and hardest task would be to
>> implement the different cases of the Computer Language Benchmarks Game in
>> standard and modern Python-Numpy. Then, optimizing and accelerating such
>> code should be doable and we should be able to get very good performance at
>> least for some cases. Good news for this project, (i) the first point can
>> be done by anyone with good knowledge in Python-Numpy (many potential
>> workers), (ii) for some cases, there are already good Python
>> implementations and (iii) the work can easily be parallelized.
>>
>> It is not a criticism, but the (beautiful and very nice) new Numpy
>> website https://numpy.org/ is not very convincing in terms of
>> performance. It's written "Performant The core of NumPy is well-optimized C
>> code. Enjoy the flexibility of Python with the speed of compiled code."
>> It's true that the core of Numpy is well-optimized C code but to seriously
>> compete with C++, Fortran or Julia in terms of numerical performance, one
>> needs to use other tools to move the compiled-interpreted boundary outside
>> the hot loops. So it could be reasonable to mention such tools (in
>> particular Numba, Pythran, Cython and Transonic).
>>
>> Is there already something planned to answer to Zwart (2020)?
>>
>> Any opinions or suggestions on this potential project?
>>
>> Pierre
>>
>> PS: Of course, alternative Python interpreters (PyPy, GraalPython,
>> Pyjion, Pyston, etc.) could also be used, especially if HPy (
>> https://github.com/hpyproject/hpy) is successful (C core of Numpy
>> written in HPy, Cython able to produce HPy code, etc.). However, I tend to
>> be a bit skeptical in the ability of such technologies to reach very high
>> performance for low-level Numpy code (performance that can be reached by
>> replacing whole Python functions with optimized compiled code). Of course,
>> I hope I'm wrong! IMHO, it does not remove the need for a successful HPy!
>>
>> --
>> Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr
>> LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
>> BP53, 38041 Grenoble Cedex, Francetel:+33.4.56.52.86.16
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>

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

[Jerome Kieffer]

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 those
statically typed ahead of time extensions (C++, C, Fortran).

Clearly the author wants to get his article viral and in a sense he
managed :). But he did not mention Julia / Numba and other JIT compiled
languages (including matlab ?) that are probably outperforming the
C++ / Fortran when considering the development time and test-time.
Beside this the OpenMP parallelism (implicitly advertized) is far from
scaling well on multi-socket systems and other programming paradigms
are needed to extract the best performances from spercomputers.

Cheers,

Jerome 

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

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

[Sebastian Berg]

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 what annoys me
> most is the compilation time needed for the development of those
> statically typed ahead of time extensions (C++, C, Fortran).
> 
> Clearly the author wants to get his article viral and in a sense he
> managed :). But he did not mention Julia / Numba and other JIT
> compiled
> languages (including matlab ?) that are probably outperforming the
> C++ / Fortran when considering the development time and test-time.
> Beside this the OpenMP parallelism (implicitly advertized) is far
> from
> scaling well on multi-socket systems and other programming paradigms
> are needed to extract the best performances from spercomputers.
> 

As an interesting aside: Algorithms may have actually improved *more*
than computational speed when it comes to performance [1].  That shows
the impressive scale and complexity of efficient code.

So, I could possibly argue that the most important thing may well be
accessibility of algorithms. And I think that is what a large chunk of
Scientific Python packages are all about.

Whether or not that has an impact on the environment...

Cheers,

Sebastian


[1] This was the first resource I found, I am sure there are plenty:
https://www.lanl.gov/conferences/salishan/salishan2004/womble.pdf


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



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

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

[Hameer Abbasi]

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.

However, this may take a while to materialize, as we need an LLVM backend, and 
a Python wrapper (matching the NumPy API), and support for arbitrary functions 
(like universal functions).

https://github.com/tensor-compiler/taco
http://fredrikbk.com/publications/kjolstad-thesis.pdf

--
Sent from Canary (https://canarymail.io)

> On Dienstag, Nov. 24, 2020 at 7:22 PM, YueCompl  (mailto:compl@icloud.com)> wrote:
> 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
>  , but that embedded DSL is far less pleasing compared to Python as the 
> surface language for optimized Numpy code in C.
>
> I imagine that we might be able to transpile a Numpy program into fused LLVM 
> IR, then deploy part as host code on CPUs and part as CUDA code on GPUs?
>
> I know Numba is already doing the array part, but it is too limited in 
> addressing more complex non-array data structures. I had been approaching 
> ~20K separate data series with some intermediate variables for each, then it 
> took up to 30+GB RAM keep compiling yet gave no result after 10+hours.
>
> Compl
>
>
> > On 2020-11-24, at 23:47, PIERRE AUGIER 
> >  > (mailto:pierre.aug...@univ-grenoble-alpes.fr)> 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://arxiv.org/pdf/2009.11295.pdf), where it is stated that "Best 
> > however, for the environment is to abandon Python for a more 
> > environmentally friendly (compiled) programming language.".
> >
> > I wrote a simple Python-Numpy implementation of the problem used for this 
> > study (https://www.nbabel.org) and, accelerated by Transonic-Pythran, it's 
> > very efficient. Here are some numbers (elapsed times in s, smaller is 
> > better):
> >
> > | # particles | Py | C++ | Fortran | Julia |
> > |-|-|-|-|---|
> > | 1024 | 29 | 55 | 41 | 45 |
> > | 2048 | 123 | 231 | 166 | 173 |
> >
> > The code and a modified figure are here: https://github.com/paugier/nbabel 
> > (There is no check on the results for https://www.nbabel.org, so one still 
> > has to be very careful.)
> >
> > I think that the Numpy community should spend a bit of energy to show what 
> > can be done with the existing tools to get very high performance (and low 
> > CO2 production) with Python. This work could be the basis of a serious 
> > reply to the comment by Zwart (2020).
> >
> > Unfortunately the Python solution in https://www.nbabel.org is very bad in 
> > terms of performance (and therefore CO2 production). It is also true for 
> > most of the Python solutions for the Computer Language Benchmarks Game in 
> > https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes here 
> > https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else).
> >
> > We could try to fix this so that people see that in many cases, it is not 
> > necessary to "abandon Python for a more environmentally friendly (compiled) 
> > programming language". One of the longest and hardest task would be to 
> > implement the different cases of the Computer Language Benchmarks Game in 
> > standard and modern Python-Numpy. Then, optimizing and accelerating such 
> > code should be doable and we should be able to get very good performance at 
> > least for some cases. Good news for this project, (i) the first point can 
> > be done by anyone with good knowledge in Python-Numpy (many potential 
> > workers), (ii) for some cases, there are already good Python 
> > implementations and (iii) the work can easily be parallelized.
> >
> > It is not a criticism, but the (beautiful and very nice) new Numpy website 
> > https://numpy.org/ is not very convincing in terms of performance. It's 
> > written "Performant The core of NumPy is well-optimized C code. Enjoy the 
> > flexibility of Python with the speed of compiled code." It's true that the 
> > core of Numpy is well-optimized C code but to seriously compete with C++, 
> > Fortran or Julia in terms of numerical performance, one needs to use other 
> > tools to move the compiled-interpreted boundary outside the hot loops. So 
> > it could be reasonable to mention such tools (in particular Numba, Pythran, 
> > Cython and Transonic).
> >
> > Is there already something planned to answer to Zwart (2020)?
> >
> > Any opinions or suggestions on this potential project?
> >
> > Pierre
> >
> > PS: Of course, alternative Python inte

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

[Ilhan Polat]

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.
There is a reason for not doing so. Alternatively, any time that will be
shaved off from this will be spent on extremely inefficient i9 laptops that
developers have while debugging the type issues. As the author themselves
admit, the development speed would justify the loss encountered from the
actual code running.

So this study is suggestive at the very least just; like my rebuttal, very
difficult to verify. I do Industrial IoT for a living, and while I
wholeheartedly agree with the intentions, I would seriously question the
power metrics given here because similarly I can easily show a steel
factory to be very efficient if I am not careful. Especially tying the code
quality to the programming language is a very slippery slope that I have
been listening to in the last 20 years from Fortran people.

> 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.

I don't get this sentence.



On Tue, Nov 24, 2020 at 7:29 PM Hameer Abbasi 
wrote:

> 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.
>
> However, this may take a while to materialize, as we need an LLVM backend,
> and a Python wrapper (matching the NumPy API), and support for arbitrary
> functions (like universal functions).
>
> https://github.com/tensor-compiler/taco
> http://fredrikbk.com/publications/kjolstad-thesis.pdf
>
> --
> Sent from Canary 
>
> On Dienstag, Nov. 24, 2020 at 7:22 PM, YueCompl 
> wrote:
> 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
>  ,
> but that embedded  DSL is far less pleasing compared to Python as the
> surface language for optimized Numpy code in C.
>
> I imagine that we might be able to transpile a Numpy program into fused
> LLVM IR, then deploy part as host code on CPUs and part as CUDA code on
> GPUs?
>
> I know Numba is already doing the array part, but it is too limited in
> addressing more complex non-array data structures. I had been approaching
> ~20K separate data series with some intermediate variables for each, then
> it took up to 30+GB RAM keep compiling yet gave no result after 10+hours.
>
> Compl
>
>
> On 2020-11-24, at 23:47, PIERRE AUGIER <
> pierre.aug...@univ-grenoble-alpes.fr> 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://arxiv.org/pdf/2009.11295.pdf), where it is stated that "Best
> however, for the environment is to abandon Python for a more
> environmentally friendly (compiled) programming language.".
>
> I wrote a simple Python-Numpy implementation of the problem used for this
> study (https://www.nbabel.org) and, accelerated by Transonic-Pythran,
> it's very efficient. Here are some numbers (elapsed times in s, smaller is
> better):
>
> | # particles |  Py | C++ | Fortran | Julia |
> |-|-|-|-|---|
> | 1024|  29 |  55 |   41|   45  |
> | 2048| 123 | 231 |  166|  173  |
>
> The code and a modified figure are here: https://github.com/paugier/nbabel
> (There is no check on the results for https://www.nbabel.org, so one
> still has to be very careful.)
>
> I think that the Numpy community should spend a bit of energy to show what
> can be done with the existing tools to get very high performance (and low
> CO2 production) with Python. This work could be the basis of a serious
> reply to the comment by Zwart (2020).
>
> Unfortunately the Python solution in https://www.nbabel.org is very bad
> in terms of performance (and therefore CO2 production). It is also true for
> most of the Python solutions for the Computer Language Benchmarks Game in
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes here
> https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else).
>
> We could try to fix this so that people see that in many cases, it is not
> necessary to "abandon Python for a more environmentally friendly (compiled)
> programming language". One of the longest and hardest task would be to
> implement the different cases of the Computer

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

[Benjamin Root]

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 pollution from power generation is
forecasted to shrink as more power is generated by alternative means. I am
fine with improving python performance, but let's not fool ourselves into
thinking that it is going to have any meaningful impact on the environment.

Ben Root

https://sustainability.aboutamazon.com/environment/the-cloud?energyType=true
https://azure.microsoft.com/en-au/global-infrastructure/sustainability/#energy-innovations
https://www.epa.gov/ghgemissions/global-greenhouse-gas-emissions-data

On Tue, Nov 24, 2020 at 1:25 PM Sebastian Berg 
wrote:

> 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 what annoys me
> > most is the compilation time needed for the development of those
> > statically typed ahead of time extensions (C++, C, Fortran).
> >
> > Clearly the author wants to get his article viral and in a sense he
> > managed :). But he did not mention Julia / Numba and other JIT
> > compiled
> > languages (including matlab ?) that are probably outperforming the
> > C++ / Fortran when considering the development time and test-time.
> > Beside this the OpenMP parallelism (implicitly advertized) is far
> > from
> > scaling well on multi-socket systems and other programming paradigms
> > are needed to extract the best performances from spercomputers.
> >
>
> As an interesting aside: Algorithms may have actually improved *more*
> than computational speed when it comes to performance [1].  That shows
> the impressive scale and complexity of efficient code.
>
> So, I could possibly argue that the most important thing may well be
> accessibility of algorithms. And I think that is what a large chunk of
> Scientific Python packages are all about.
>
> Whether or not that has an impact on the environment...
>
> Cheers,
>
> Sebastian
>
>
> [1] This was the first resource I found, I am sure there are plenty:
> https://www.lanl.gov/conferences/salishan/salishan2004/womble.pdf
>
>
> > Cheers,
> >
> > Jerome
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

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-of-the-environment to be a bit
> disingenuous. Especially since GHG pollution from power generation is
> forecasted to shrink as more power is generated by alternative means. I am
> fine with improving python performance, but let's not fool ourselves into
> thinking that it is going to have any meaningful impact on the environment.
>
> Ben Root
>

Bingo. I lived through the Freon ozone panic that lasted for 20 years even
after the key reaction rate was remeasured and found to be 75-100 times
slower than that used in the research that started the panic. The models
never recovered, but the panic persisted until it magically disappeared in
1994. There are still ozone holes over the Antarctic, last time I looked
they were explained as due to an influx of cold air.

If you want to deal with GHG, push nuclear power.



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

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

[Benjamin Root]

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
the CFC+sunlight+O3 reaction rate. Note that it doesn't mean that 50 years
are needed to get rid of all CFCs in the atmosphere, it is just a measure
of the amount of time it is expected to take for half of the gas that is
already there to be removed. That doesn't account for the amount of time it
has taken for CFC usage to drop in the first place, and the fact that there
are still CFC pollution occurring (albeit far less than in the 80's).

Ben Root

https://ozone.unep.org/nasa-provides-first-direct-evidence-ozone-hole-recovery
https://csl.noaa.gov/assessments/ozone/1998/faq11.html


On Tue, Nov 24, 2020 at 2:07 PM Charles R Harris 
wrote:

>
>
> 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-of-the-environment to be a bit
>> disingenuous. Especially since GHG pollution from power generation is
>> forecasted to shrink as more power is generated by alternative means. I am
>> fine with improving python performance, but let's not fool ourselves into
>> thinking that it is going to have any meaningful impact on the environment.
>>
>> Ben Root
>>
>
> Bingo. I lived through the Freon ozone panic that lasted for 20 years even
> after the key reaction rate was remeasured and found to be 75-100 times
> slower than that used in the research that started the panic. The models
> never recovered, but the panic persisted until it magically disappeared in
> 1994. There are still ozone holes over the Antarctic, last time I looked
> they were explained as due to an influx of cold air.
>
> If you want to deal with GHG, push nuclear power.
>
> 
>
> Chuck
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

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 because of certain ice crystal formations that give a boost in
> the CFC+sunlight+O3 reaction rate. Note that it doesn't mean that 50 years
> are needed to get rid of all CFCs in the atmosphere, it is just a measure
> of the amount of time it is expected to take for half of the gas that is
> already there to be removed. That doesn't account for the amount of time it
> has taken for CFC usage to drop in the first place, and the fact that there
> are still CFC pollution occurring (albeit far less than in the 80's).
>
> Ben Root
>
>
Out of curiosity, has the ice crystal acceleration been established in the
lab? I recall it being proposed to help save the models, but that was a
long time ago. IIRC, another reaction rate was remeasured in 2005 and found
to be 10X lower than thought, but don't recall which one. I've been looking
for a good recent review article to see what the current status is. The
funding mostly disappeared after 1994 along with several careers. Freon is
still used -- off the books -- in several countries, a phenomenon now seen
with increasing coal generation.

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

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

[Alan G. Isaac]

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 layer thinning. Is there
a particular model you have in mind? (Ideally one with publicly available
source code and some data.)



On 11/24/2020 2:06 PM, Charles R Harris wrote:

If you want to deal with GHG, push nuclear power.


Yes. However, solar is becoming competitive is some regions
for cost per watt, and avoids the worst waste disposal issues.

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

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

[Aaron Meurer]

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 a long time to run. If I have two codes that
compute the same thing and one takes a week and the other takes a few
minutes, then obviously I will choose the one that takes a few
minutes, and my decision will have nothing to do with ecological
impact. The real issue with CO2 emissions are instances where the
agency is completely removed and the people damaging the environment
don't suffer any ill effects from it.

It would be more intellectually honest to try to determine why it is
that people choose Python, an apparently very slow language, to do
high performance computing. If one spends even a moment thinking about
this, and actually looking at what the real scientific Python
community does, one would realize that simply having a fast core in
Python is enough for the majority of performance. NumPy array
expressions are fast because the core loops are fast, and those
dominate the runtime for the majority of uses. And for instances where
it isn't fast enough, e.g., when writing a looping algorithm directly,
there are multiple tools that allow writing fast Python or Python-like
code, such as Numba, Cython, Pythran, PyPy, and so on.

Aaron Meurer

On Tue, Nov 24, 2020 at 8:57 AM 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://arxiv.org/pdf/2009.11295.pdf), where it is stated that "Best however, 
> for the environment is to abandon Python for a more environmentally friendly 
> (compiled) programming language.".
>
> I wrote a simple Python-Numpy implementation of the problem used for this 
> study (https://www.nbabel.org) and, accelerated by Transonic-Pythran, it's 
> very efficient. Here are some numbers (elapsed times in s, smaller is better):
>
> | # particles |  Py | C++ | Fortran | Julia |
> |-|-|-|-|---|
> | 1024|  29 |  55 |   41|   45  |
> | 2048| 123 | 231 |  166|  173  |
>
> The code and a modified figure are here: https://github.com/paugier/nbabel 
> (There is no check on the results for https://www.nbabel.org, so one still 
> has to be very careful.)
>
> I think that the Numpy community should spend a bit of energy to show what 
> can be done with the existing tools to get very high performance (and low CO2 
> production) with Python. This work could be the basis of a serious reply to 
> the comment by Zwart (2020).
>
> Unfortunately the Python solution in https://www.nbabel.org is very bad in 
> terms of performance (and therefore CO2 production). It is also true for most 
> of the Python solutions for the Computer Language Benchmarks Game in 
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes here 
> https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else).
>
> We could try to fix this so that people see that in many cases, it is not 
> necessary to "abandon Python for a more environmentally friendly (compiled) 
> programming language". One of the longest and hardest task would be to 
> implement the different cases of the Computer Language Benchmarks Game in 
> standard and modern Python-Numpy. Then, optimizing and accelerating such code 
> should be doable and we should be able to get very good performance at least 
> for some cases. Good news for this project, (i) the first point can be done 
> by anyone with good knowledge in Python-Numpy (many potential workers), (ii) 
> for some cases, there are already good Python implementations and (iii) the 
> work can easily be parallelized.
>
> It is not a criticism, but the (beautiful and very nice) new Numpy website 
> https://numpy.org/ is not very convincing in terms of performance. It's 
> written "Performant The core of NumPy is well-optimized C code. Enjoy the 
> flexibility of Python with the speed of compiled code." It's true that the 
> core of Numpy is well-optimized C code but to seriously compete with C++, 
> Fortran or Julia in terms of numerical performance, one needs to use other 
> tools to move the compiled-interpreted boundary outside the hot loops. So it 
> could be reasonable to mention such tools (in particular Numba, Pythran, 
> Cython and Transonic).
>
> Is there already something planned to answer to Zwart (2020)?
>
> Any opinions or suggestions on this potential project?
>
> Pierre
>
> PS: Of course, alternative Python interpreters (PyPy, GraalPython, Pyjion, 
> Pyston, etc.) could also be used, especially if HPy 
> (https://github.com/hpyproject/hpy) is successful (C core of Numpy written in 
> HPy, Cython able to produce HPy cod

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

[YueCompl]

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
 

 , but that embedded  DSL is far less pleasing compared to Python as the 
surface language for optimized Numpy code in C. 

I imagine that we might be able to transpile a Numpy program into fused LLVM 
IR, then deploy part as host code on CPUs and part as CUDA code on GPUs?

I know Numba is already doing the array part, but it is too limited in 
addressing more complex non-array data structures. I had been approaching ~20K 
separate data series with some intermediate variables for each, then it took up 
to 30+GB RAM keep compiling yet gave no result after 10+hours.

Compl


> On 2020-11-24, at 23:47, 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://arxiv.org/pdf/2009.11295.pdf), where it is stated that "Best however, 
> for the environment is to abandon Python for a more environmentally friendly 
> (compiled) programming language.".
> 
> I wrote a simple Python-Numpy implementation of the problem used for this 
> study (https://www.nbabel.org) and, accelerated by Transonic-Pythran, it's 
> very efficient. Here are some numbers (elapsed times in s, smaller is better):
> 
> | # particles |  Py | C++ | Fortran | Julia |
> |-|-|-|-|---|
> | 1024|  29 |  55 |   41|   45  |
> | 2048| 123 | 231 |  166|  173  |
> 
> The code and a modified figure are here: https://github.com/paugier/nbabel 
> (There is no check on the results for https://www.nbabel.org, so one still 
> has to be very careful.)
> 
> I think that the Numpy community should spend a bit of energy to show what 
> can be done with the existing tools to get very high performance (and low CO2 
> production) with Python. This work could be the basis of a serious reply to 
> the comment by Zwart (2020).
> 
> Unfortunately the Python solution in https://www.nbabel.org is very bad in 
> terms of performance (and therefore CO2 production). It is also true for most 
> of the Python solutions for the Computer Language Benchmarks Game in 
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes here 
> https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else).
> 
> We could try to fix this so that people see that in many cases, it is not 
> necessary to "abandon Python for a more environmentally friendly (compiled) 
> programming language". One of the longest and hardest task would be to 
> implement the different cases of the Computer Language Benchmarks Game in 
> standard and modern Python-Numpy. Then, optimizing and accelerating such code 
> should be doable and we should be able to get very good performance at least 
> for some cases. Good news for this project, (i) the first point can be done 
> by anyone with good knowledge in Python-Numpy (many potential workers), (ii) 
> for some cases, there are already good Python implementations and (iii) the 
> work can easily be parallelized.
> 
> It is not a criticism, but the (beautiful and very nice) new Numpy website 
> https://numpy.org/ is not very convincing in terms of performance. It's 
> written "Performant The core of NumPy is well-optimized C code. Enjoy the 
> flexibility of Python with the speed of compiled code." It's true that the 
> core of Numpy is well-optimized C code but to seriously compete with C++, 
> Fortran or Julia in terms of numerical performance, one needs to use other 
> tools to move the compiled-interpreted boundary outside the hot loops. So it 
> could be reasonable to mention such tools (in particular Numba, Pythran, 
> Cython and Transonic).
> 
> Is there already something planned to answer to Zwart (2020)?
> 
> Any opinions or suggestions on this potential project?
> 
> Pierre
> 
> PS: Of course, alternative Python interpreters (PyPy, GraalPython, Pyjion, 
> Pyston, etc.) could also be used, especially if HPy 
> (https://github.com/hpyproject/hpy) is successful (C core of Numpy written in 
> HPy, Cython able to produce HPy code, etc.). However, I tend to be a bit 
> skeptical in the ability of such technologies to reach very high performance 
> for low-level Numpy code (performance that can be reached by replacing whole 
> Python functions with optimized compiled code). Of course, I hope I'm wrong! 
> IMHO, it does not remove the need for a successful HPy!
> 
> --
> Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr
> LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
> BP53, 38041 Grenoble Cedex, Francetel:+33.4.56.5

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

[Thomas]

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 did not think much about it and solved it with if-else statements.

But yes, maybe this is too specific and trivial for a Numpy function.

Thanks for taking the time to look into it!

On Tue, 24 Nov 2020 at 15:47, Ralf Gommers  wrote:

>
>
> 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 convenient.
>>
>> Which edge cases? Better how?
>>
>> > And as the "unwrap" function already exists,
>>
>> The unwrap() function exists because it is not as trivial.
>>
>
> I agree, we prefer not to add trivial functions like this. To help those
> few people that may need this, maybe just add the one-liner Daniele gave to
> the Notes section of unwrap()?
>
> Cheers,
> Ralf
>
>
>
>> > people would expect that
>> > and look for a function for the inverse operation (at least I did).
>>
>> What is your use of a wrap() function? I cannot think of any.
>>
>> Cheers,
>> Dan
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Sebastian Berg]

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
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

[Eric Moore]

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 convenient.
>
> Which edge cases? Better how?
>
> > And as the "unwrap" function already exists,
>
> The unwrap() function exists because it is not as trivial.
>
> > people would expect that
> > and look for a function for the inverse operation (at least I did).
>
> What is your use of a wrap() function? I cannot think of any.
>
> Cheers,
> Dan
>


For what it’s worth, this kind of range reduction  can be extremely
nontrivial depending on the needs of your application.   Look at the
efforts needed to ensure that the trigonometric functions give good
results. This is discussed in this paper:
https://www.csee.umbc.edu/~phatak/645/supl/Ng-ArgReduction.pdf.

I don’t think that this belongs in Numpy, but it certainly isn’t a one
liner.

Best,

Eric



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