The ufunc approach makes sense. Something like abs2 is essential for anyone who does signal processing simulations using NumPy.
Phillip On Sat, Oct 10, 2015 at 11:29 AM, Nathaniel Smith <n...@pobox.com> wrote: > On Oct 10, 2015 10:50 AM, "Charles R Harris" <charlesr.har...@gmail.com> > wrote: > > > > On Sat, Oct 10, 2015 at 11:14 AM, Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > >> > >> > We tend to avoid adding methods. 2) would be a very easy enhancement, > just a slight modification of sqr. > >> > >> Did you mean `np.square`? Sadly, that doesn't do the right thing: > `np.square(1+1j)` yields `2j`, while one wants `c*c.conj()` and thus `2`. > Or, for fastest speed, really just `c.real**2 + c.imag**2`. > > > > > > Yes, I meant the new function could made by reusing the square code with > slight modifications. > > > >> > >> My guess would be that a new ufunc, say `np.abs2` or `np.modulus2` or > so, would be more appropriate than defining a new method. I'd also be > hesitant to define a new private method -- I like how those usually are > just used to override python basics. > > > > > > Julia uses abs2. > > I don't have an opinion on whether abs2 is important enough to bother with > (I don't work much with complex numbers myself, nor have I run any > benchmarks), but I agree that if we do want it then adding it as a regular > ufunc would definitely be the right approach. > > -n > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
