Re: [Numpy-discussion] Converting np.sinc into a ufunc

It might be worth using BigQuery to search the github repository public dataset for usages of np.sinc with keyword arguments. On Wed, May 22, 2019 at 1:05 PM Sebastian Berg wrote: > Hi all, > > there is an open PR (https://github.com/numpy/numpy/pull/12924) to > convert `np.sinc` into a ufunc.

[Numpy-discussion] [ANN] 2019 Scipy Conference: Call for Proposals

SciPy 2019, the 18th annual Scientific Computing with Python conference, will be held July 8-14, 2019 in Austin, Texas. The annual SciPy Conference brings together over 800 participants from industry, academia, and government to showcase their latest projects, learn from skilled users and

Re: [Numpy-discussion] Taking back control of the #numpy irc channel

Hi, I idle in #scipy and have op in there. I’m happy start idling in #numpy and be op if the community is willing to let me. I’m also in the process of getting ops for #matplotlib for similar spam-related reasons. I’d say all the scientific python IRC channels I’m in get a decent amount of

Re: [Numpy-discussion] Adoption of a Code of Conduct

On Wed, Aug 1, 2018 at 9:49 AM, Ralf Gommers wrote: > > > On Wed, Aug 1, 2018 at 12:20 AM, Nathan Goldbaum > wrote: > >> I realize this was probably brought up in the discussions about the scipy >> code of conduct which I have not looked at, but I’m troubled by the

Re: [Numpy-discussion] NumPy 1.15.0rc2 released.

Hi Chuck, Is there a summary of the differences with respect to rc1 somewhere? Nathan On Mon, Jul 9, 2018 at 5:08 PM Charles R Harris wrote: > Hi All, > > On behalf of the NumPy team I'm pleased to announce the release of NumPy > 1.15.0rc2. > This release has an unusual number of cleanups,

Re: [Numpy-discussion] PEP 574 - zero-copy pickling with out of band data

On Mon, Jul 2, 2018 at 7:42 PM Andrew Nelson wrote: > > > On Tue, 3 Jul 2018 at 09:31, Charles R Harris > wrote: > >> >> ISTR that some parallel processing applications sent pickled arrays >> around to different processes, I don't know if that is still the case, but >> if so, no copy might be

Re: [Numpy-discussion] rackspace ssl certificates

I think Matthew Brett needs to fix this. On Mon, Jun 18, 2018 at 3:20 PM Charles R Harris wrote: > Hi All, > > I've been trying to put out the NumPy 1.15.0rc1, but cannot get > `numpy-wheels` to upload the wheels to rackspace on windows, there is a > certification problem. I note that that

Re: [Numpy-discussion] Updated 1.15.0 release notes

with the prerelease so numpy and other projects can implement workarounds as needed without doing a release that might potentially break real users who happen to install right after numpy 1.x.0 comes out. Best, Nathan Goldbaum On Wed, Jun 13, 2018 at 7:11 PM Charles R Harris wrote: > Hi

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Hmm, does this mean the callable that gets passed into __array_ufunc__ will change? I'm pretty sure that will break the dispatch mechanism I'm using in my __array_ufunc__ implementation, which directly checks whether the callable is in one of several tuples of functions that have different

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Perhaps I missed this but I didn’t see: what happens when both __array_ufunc__ and __array_function__ are defined? I might want to do this to for example add support for functions like concatenate or stack to a class that already has an __array_ufunc__ defines. On Sat, Jun 2, 2018 at 5:56 PM

[Numpy-discussion] Citation for ndarray

Hi all, I see listed on the scipy.org site that the preferred citation for NumPy is the "Guide to NumPy": https://www.scipy.org/citing.html This could work for what I'm writing, but I'd prefer to find a citation specifically for NumPy's ndarray data structure. Does such a citation exist?

Re: [Numpy-discussion] Turn numpy.ones_like into a ufunc

I don't particularly need this, although it would be nice to make this behavior explicit, instead of happening more or less by accident: In [1]: from yt.units import km In [2]: import numpy as np In [3]: data = [1, 2, 3]*km In [4]: np.ones_like(data) Out[4]: YTArray([1.,

Re: [Numpy-discussion] Casting scalars

On Thu, May 10, 2018 at 9:51 PM Stuart Reynolds wrote: > np.float(scalar) > This actually isn't right. It's a common misconception, but np.float is an alias to the built-in float type. You probably want np.float_(scalar) In [5]: np.float_(12).dtype Out[5]:

Re: [Numpy-discussion] Casting scalars

In [1]: import numpy as np In [2]: np.float64(12) Out[2]: 12.0 In [3]: np.float64(12).dtype Out[3]: dtype('float64') On Thu, May 10, 2018 at 9:49 PM Hameer Abbasi wrote: > Hello, everyone! > > I might be missing something and this might be a very stupid and

Re: [Numpy-discussion] Short-circuiting equivalent of np.any or np.all?

in duck arrays, etc) >> >> Best regards, >> Hameer Abbasi >> Sent from Astro <https://www.helloastro.com> for Mac >> >> On Apr 26, 2018 at 18:45, Nathan Goldbaum <nathan12...@gmail.com> wrote: >> >> >> Hi all, >> >> I was su

Re: [Numpy-discussion] Short-circuiting equivalent of np.any or np.all?

t I want in NumPy or some other package. > > Best regards, > Hameer Abbasi > Sent from Astro <https://www.helloastro.com> for Mac > > On Apr 26, 2018 at 18:45, Nathan Goldbaum <nathan12...@gmail.com> wrote: > > > Hi all, > > I was surprised recently to di

[Numpy-discussion] Short-circuiting equivalent of np.any or np.all?

Hi all, I was surprised recently to discover that both np.any and np.all() do not have a way to exit early: In [1]: import numpy as np In [2]: data = np.arange(1e6) In [3]: print(data[:10]) [0. 1. 2. 3. 4. 5. 6. 7. 8. 9.] In [4]: %timeit np.any(data) 724 us +- 42.4 us per loop (mean +- std.

Re: [Numpy-discussion] Introduction: NumPy developers at BIDS

On Tue, Apr 10, 2018 at 9:59 AM, Stefan van der Walt wrote: > Hi Eric, > > On Sun, 08 Apr 2018 08:02:19 -1000, Eric Firing wrote: > > On 2018/04/07 9:19 PM, Stefan van der Walt wrote: > > > We would love community input on identifying the best areas & issues to > > > pay

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Thu, Nov 2, 2017 at 5:21 PM, Stephan Hoyer <sho...@gmail.com> wrote: > On Thu, Nov 2, 2017 at 12:42 PM Nathan Goldbaum <nathan12...@gmail.com> > wrote: > >> Would this issue be ameliorated given Nathaniel's proposal to try to move >> away from subclasses a

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

I think the biggest issues could be resolved if __array_concatenate__ were finished. Unfortunately I don't feel like I can take that on right now. See Ryan May's talk at scipy about using an ndarray subclass for units and the issues he's run into: https://www.youtube.com/watch?v=qCo9bkT9sow On

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

I’m using it in yt. If we were able to drop support for all old numpy versions, switching would allow me to delete hundreds of lines of code. As-is since we need to simultaneously support old and new versions, it adds some additional complexity. If you’re ok with only supporting numpy >= 1.13,

Re: [Numpy-discussion] numpy grant update

My understanding of this is that the dtype will only hold the unit metadata. So that means units would propogate through calculations automatically, but the dtype wouldn't be able to manipulate the array data (in an in-place unit conversion for example). In this world, astropy quantities and yt's

Re: [Numpy-discussion] Github overview change

This is a change in the UI that github introduced a couple weeks ago during their annual conference. See https://github.com/blog/2447-a-more-connected-universe On Wed, Oct 18, 2017 at 11:49 AM Charles R Harris wrote: > On Wed, Oct 18, 2017 at 7:23 AM, Sebastian Berg

Re: [Numpy-discussion] Dropping support for Accelerate

See https://mail.scipy.org/pipermail/numpy-discussion/2012-August/063589.html and replies in that thread. Quote from an Apple engineer in that thread: "For API outside of POSIX, including GCD and technologies like Accelerate, we do not support usage on both sides of a fork(). For this reason

Re: [Numpy-discussion] Controlling NumPy __mul__ method or forcing it to use __rmul__ of the "other"

I don't think there's any real standard here. Just doing a github search reveals many different choices people have used: https://github.com/search?l=Python=__array_priority__=Code=%E2%9C%93 On Mon, Jun 19, 2017 at 11:07 AM, Ilhan Polat wrote: > Thank you. I didn't know

Re: [Numpy-discussion] __array_ufunc__ counting down to launch, T-24 hrs.

Thanks for linking to the updated NEP, I've been looking for a good overview of this discussion. Up until now I haven't wanted to wade through the extensive discussion on this topic. I'm curious, if I want to simultaneously support older Numpy versions as well as newer versions, will I be able to