<p dir="ltr">On Oct 10, 2015 10:50 AM, "Charles R Harris" <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
> On Sat, Oct 10, 2015 at 11:14 AM, Marten van Kerkwijk <<a href="mailto:m.h.vankerkwijk@gmail.com">m.h.vankerkwijk@gmail.com</a>> wrote:<br>
>><br>
>> > We tend to avoid adding methods. 2) would be a very easy enhancement, just a slight modification of sqr.<br>
>><br>
>> 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`.<br>
><br>
><br>
> Yes, I meant the new function could made by reusing the square code with slight modifications.<br>
><br>
>><br>
>> 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.<br>
><br>
><br>
> Julia uses abs2.</p>
<p dir="ltr">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.</p>
<p dir="ltr">-n</p>