[Numpy-discussion] Re: Numpy-related jobs, grants, etc
On Tue, May 3, 2022 at 5:05 PM Renato Fabbri wrote: > This is not only for me, but a question for the community in general. > Do we have an open knowledge base of budget (interested companies or > individuals, public funding) > for developing numpy-related packages? > Hi Renato, no we don't have that. Nor does it seem like an easy thing to develop in general, since it's so broad and can change quickly. If you browse the NumFOCUS website you will get a part of the picture. We've also announced grants and other support we've received for NumPy itself on this list. For building on top of NumPy though - that's a whole ecosystem. You won't find a comprehensive answer anywhere I'm afraid. > Explaining a bit with a specific case... > In the last few years, I have many times thought about the possibility of > working with Numpy: > finding payment for developing libraries using Numpy or even Numpy > internals. > "NumPy internals" vs. "libraries using NumPy" is very distinct. Only the former is on-topic here. > Especially, I have written a music python library (called 'music' on PyPI). > It holds many useful things, equal-loudness contours, musical notes, > localization, HRTF, LUT, singing, glissandi, tremolos & vibratos with > transitions, etc etc. > I believe it is something well done, which involved scientific research > and over a decade of experience with the algorithms, but it still lacks a > better organization of the functionalities, better documentation, and > better maintenance. > To reach that point, one would probably have to be paid to take the > necessary time. > To give you a frank assessment: you won't find grant funding opportunities in the places we're getting other funding. Your best bets are: 1. Individual sponsorship from people who care about what you make - GitHub Sponsors, Patreon, etc. 2. A funder primarily interested in music & (digital) culture. That assumes that your project is at least best-in-class. > > Beyond that, I know it is useful for making art/music, teaching, learning > music, learning music-related signal processing and programming, etc. > > Maybe the most important point: this is probably the case with other > libraries/projects. > > ((( > On the other side, we as a company (here at Modena/Italy) may look into > (public, private, own) funding > to develop Numpy (internals, libraries). > We would also enjoy developing Numpy-related libraries (internals?) if > someone needs or wants them. > ))) > We have a public roadmap (see https://numpy.org/neps/) for what we think is needed most. If you are serious about funding work on NumPy, we'd be happy to discuss that. Cheers, Ralf > Should this be posted in another list/forum? > Any thoughts? > R. > > -- > Renato Fabbri > -- > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: ralf.gomm...@googlemail.com > ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] overhead of numpy scalars
Hi everyone,
Operations such as np.sqrt or np.cos on numpy scalars are much slower than
operations on an array of size 1 (benchmark below). The reason seems to be
that a numpy scalar (e.g. np.float64(1.1)) is converted internally to an
array, an array is created for the result of the operation and the result
is converted back to a scalar (so three object constructions in total).
Operating directly on an array creates an array for the result, which is
returned (so one object construction in total).
Has anyone looked into improving this performance before or has ideas how
to tackle this?
With kind regards,
Pieter Eendebak
Example benchmark:
import numpy as np
from numpy import sqrt
import time
v=np.array([1.1])
t0=time.perf_counter()
x=np.float64(v)
for kk in range(1_000_000):
w1=sqrt(x)
dt1=time.perf_counter()-t0
print(dt1)
t0=time.perf_counter()
x=v
for kk in range(1_000_000):
w2=sqrt(x)
dt2=time.perf_counter()-t0
print(dt2)
print(f'factor {dt1/dt2:.2f} faster')
assert(float(w1)==float(w2))
Results in
1.0878291579974757
0.511536967245
factor 2.13 faster
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
[Numpy-discussion] Re: overhead of numpy scalars
On Tue, 2022-05-03 at 15:06 +0200, Pieter Eendebak wrote:
> Hi everyone,
>
> Operations such as np.sqrt or np.cos on numpy scalars are much slower
> than
> operations on an array of size 1 (benchmark below). The reason seems
> to be
> that a numpy scalar (e.g. np.float64(1.1)) is converted internally to
> an
> array, an array is created for the result of the operation and the
> result
> is converted back to a scalar (so three object constructions in
> total).
> Operating directly on an array creates an array for the result, which
> is
> returned (so one object construction in total).
>
> Has anyone looked into improving this performance before or has ideas
> how
> to tackle this?
Improvements certainly here and there, but very little in terms of a
larger effort. But not a coordinated effort to try to get the scalar
performance closer to the array one here.
It is a bit tricky, since at least I have little appetite to duplicate
a big chunk of the ufunc machinery.
I could think of a few things:
1. We need to special case things so the `__array_ufunc__` overhead
goes away. That needs a good idea... or just a fast check for
NumPy scalars.
2. If we stick with arrays internally, improve the scalar -> array
conversion. Things that could help here:
* A free-list for 0-D arrays (with small itemsize)?
* Some fast paths to skip dtype/shape discovery here?
Unless we want to look into writing a "scalar ufunc" machinery (we
almost have a start for that in the scalar math, but ufuncs are much
more flexible than simple math).
It would be nice if we can chip away at improving things, but right now
I do not have a good plan of how to level the performance gap.
A super-fast scalar check (we have one that might just work), may help
with both of the points above I guess.
Cheers,
Sebastian
[1] To be fair, I may have removed some fast-paths there, but I don't
recall slowing things down, so I either sped things up elsewhere or
they were not thorough enough anyway probably.
>
> With kind regards,
> Pieter Eendebak
>
> Example benchmark:
>
> import numpy as np
> from numpy import sqrt
> import time
>
> v=np.array([1.1])
> t0=time.perf_counter()
> x=np.float64(v)
> for kk in range(1_000_000):
> w1=sqrt(x)
> dt1=time.perf_counter()-t0
> print(dt1)
>
> t0=time.perf_counter()
> x=v
> for kk in range(1_000_000):
> w2=sqrt(x)
> dt2=time.perf_counter()-t0
> print(dt2)
>
> print(f'factor {dt1/dt2:.2f} faster')
> assert(float(w1)==float(w2))
>
> Results in
>
> 1.0878291579974757
> 0.511536967245
> factor 2.13 faster
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: sebast...@sipsolutions.net
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
[Numpy-discussion] NumPy Newcomers' Hour – Thursday, May 5th, 2022
The next Newcomers' Hour will be held tomorrow, May 5th, at 4 pm UTC. Stop by to ask questions or just to say hi as we don't have an agenda for this meeting. Join us via Zoom: https://us02web.zoom.us/j/87192457898 Cheers, Inessa Inessa Pawson NumPy Contributor Experience Lead ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
