Re: [Numpy-discussion] MATLAB to Numpy
Hmm, so how come this doesn't work now? mask = ((px > 2.) & ((py**2 + pz**2) / px**2 < 1.)) for arr in (px, py, pz, w, x, y, z): arr = arr[mask] On Mon, 23 Oct 2017 15:05:26 +0200 (CEST), "Andrei Berceanu" wrote: > Thank you so much, the solution was much simpler than I expected! > > On Sat, 21 Oct 2017 23:04:43 +0200, Daπid wrote: > > > On 21 October 2017 at 22:32, Eric Wieser > > wrote: > > > > > David, that doesn’t work, because np.cumsum(mask)[mask] is always equal > > > to np.arange(mask.sum()) + 1. Robert’s answer is correct. > > > > > Of course, you are right. It makes sense in my head now. > > ___ > > 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] MATLAB to Numpy
In what way does it not work? Does it error out at the `arr = arr[mask]` step? Or is it that something unexpected happens? I am guessing that you are trying to mutate the px, py, pz, w, x, y, z arrays? If so, that for-loop won't do it. In python, a plain simple assignment merely makes the variable point to a different object. It doesn't mutate the object itself. Cheers! Ben Root On Fri, Oct 27, 2017 at 11:43 AM, Andrei Berceanu wrote: > Hmm, so how come this doesn't work now? > > mask = ((px > 2.) & ((py**2 + pz**2) / px**2 < 1.)) > > for arr in (px, py, pz, w, x, y, z): > arr = arr[mask] > > On Mon, 23 Oct 2017 15:05:26 +0200 (CEST), "Andrei Berceanu" < > berce...@runbox.com> wrote: > > > Thank you so much, the solution was much simpler than I expected! > > > > On Sat, 21 Oct 2017 23:04:43 +0200, Daπid wrote: > > > > > On 21 October 2017 at 22:32, Eric Wieser > > > wrote: > > > > > > > David, that doesn’t work, because np.cumsum(mask)[mask] is always > equal > > > > to np.arange(mask.sum()) + 1. Robert’s answer is correct. > > > > > > > Of course, you are right. It makes sense in my head now. > > > ___ > > > 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 grant update
> Date: Thu, 26 Oct 2017 17:27:33 -0400 > From: Marten van Kerkwijk > > That sounds somewhat puzzling as units cannot really propagate without > them somehow telling how they would change! (e.g., the outcome of > sin(a) is possible only for angular units and then depends on that > unit). But in any case, the mailing list is probably not the best case > to discuss this - rather, I look forward to -- and will most happily > give feedback on -- a NEP or other more detailed explanation! > So whilst it’s true that trigonometric functions only make sense for dimensionless quantities, you might still want to compute them for dimensional quantities for reasons of computational efficiency. Taking your example of sin(a) in a spectral density identity: log(cos(ka) + i sin(ka)) = k log(cos(a) + i sin(a)) so if you are computing the LHS for many k and a single a (i.e k the wavenumber and ka dimensionless) then you might prefer the RHS, which actually uses sin(a). Peter ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] is __array_ufunc__ ready for prime-time?
Right before 1.12, I arranged an API around an np.ndarray subclass, making use of __array_ufunc__ to customize behavior based on structured dtype (we come from c++ and really like operator overloading). Having seen __array_ufunc__ featured in Travis Oliphant's Guide to NumPy: 2nd Edition, I assumed this was the way to go. But it was removed in 1.12. Now that 1.13 has reintroduced __array_ufunc__, can I now rely on its continued availability? I am considering using it as a base-level component in several libraries... is this a dangerous idea? Thanks! Will -- William H. Sheffler Ph.D. Principal Engineer Institute for Protein Design University of Washington ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?
Hi Will, We spent a *long time* sorting out the messy details of __array_ufunc__ [1], especially for handling interactions between different types, e.g., between numpy arrays, non-numpy array-like objects, builtin Python objects, objects that override arithmetic to act in non-numpy-like ways, and of course subclasses of all the above. We hope that we have it right this time, but as we wrote in the NumPy 1.13 release notes "The API is provisional, we do not yet guarantee backward compatibility as modifications may be made pending feedback." That said, let's give it a try! If any changes are necessary, I expect it would likely relate to how we handle interactions between different types. That's where we spent the majority of the design effort, but debate is a poor substitute for experience. I would be very surprised if the basic cases (one argument or two arguments of the same type) need any changes. Best, Stephan [1] https://docs.scipy.org/doc/numpy-1.13.0/neps/ufunc-overrides.html On Fri, Oct 27, 2017 at 12:39 PM William Sheffler wrote: > Right before 1.12, I arranged an API around an np.ndarray subclass, making > use of __array_ufunc__ to customize behavior based on structured dtype (we > come from c++ and really like operator overloading). Having seen > __array_ufunc__ featured in Travis Oliphant's Guide to NumPy: 2nd Edition, > I assumed this was the way to go. But it was removed in 1.12. Now that 1.13 > has reintroduced __array_ufunc__, can I now rely on its continued > availability? I am considering using it as a base-level component in > several libraries... is this a dangerous idea? > > Thanks! > Will > > -- > William H. Sheffler Ph.D. > Principal Engineer > Institute for Protein Design > University of Washington > ___ > 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] is __array_ufunc__ ready for prime-time?
Just to second Stephan's comment: do try it! I've moved astropy's Quantity over to it, and am certainly counting on the basic interface staying put... -- Marten ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] MATLAB to Numpy
One way would be ``` px, py, pz, w, x, y, z = [arr[mask] for arr in px, py, pz, w, x, y, z] ``` -- Marten ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy grant update
Hi Peter, When using units, if `a` is not angular (or dimensionless), I don't see how one could write code in which your example wouldn't fail... But I may be missing something, since for your example one would just realize that cos(ka)+i sin(ka) = exp(ika), in which case the log is just ika and one can the whole complexity... All the best, Marten On Fri, Oct 27, 2017 at 3:24 PM, Peter Creasey wrote: >> Date: Thu, 26 Oct 2017 17:27:33 -0400 >> From: Marten van Kerkwijk >> >> That sounds somewhat puzzling as units cannot really propagate without >> them somehow telling how they would change! (e.g., the outcome of >> sin(a) is possible only for angular units and then depends on that >> unit). But in any case, the mailing list is probably not the best case >> to discuss this - rather, I look forward to -- and will most happily >> give feedback on -- a NEP or other more detailed explanation! >> > > > So whilst it’s true that trigonometric functions only make sense for > dimensionless quantities, you might still want to compute them for > dimensional quantities for reasons of computational efficiency. Taking > your example of sin(a) in a spectral density identity: > > log(cos(ka) + i sin(ka)) = k log(cos(a) + i sin(a)) > > so if you are computing the LHS for many k and a single a (i.e k the > wavenumber and ka dimensionless) then you might prefer the RHS, which > actually uses sin(a). > > Peter > ___ > 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] 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, array_ufunc will make you life a lot easier. On Fri, Oct 27, 2017 at 6:55 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Just to second Stephan's comment: do try it! I've moved astropy's > Quantity over to it, and am certainly counting on the basic interface > staying put... -- Marten > ___ > 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] is __array_ufunc__ ready for prime-time?
Hi Nathan, Happy to hear that it works well for yt! In astropy's Quantity as well, it greatly simplifies the code, and has made many operations about two times faster (which is why I pushed so hard to get __array_ufunc__ done...). But for now we're stuck with supporting __array_prepare__ and __array_wrap__ as well. Of course, do let us know if there are issues with the current design. Some further cleanup, especially with the use of `super` for ndarray subclasses, is still foreseen (but none of that should impact the API). All the best, Marten ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
