> However, nans have been propagated by maximum and minimum since 1.4.0.
> There was a question, discussed on the list, as to what 'nan' complex to
> return in the propagation, but it was still a nan complex in your
> definition of such objects. The final choice was driven by using the
> first of
On Sun, Jul 18, 2010 at 3:36 PM, Pauli Virtanen wrote:
> Hi,
>
> The current way of Numpy handles ordering of complex nan is not very well
> defined. We should attempt to clarify this for 1.5.0.
>
> For example, what should these return:
>
>r1 = np.maximum(complex(1, nan), complex(2, 0))
>
>
On Sun, Jul 18, 2010 at 5:00 PM, Pauli Virtanen wrote:
> Sun, 18 Jul 2010 15:57:47 -0600, Charles R Harris wrote:
> > On Sun, Jul 18, 2010 at 3:36 PM, Pauli Virtanen wrote:
> [clip]
> >> I suggest the following, aping the way the real nan works:
> >>
> >> - (z, nan), (nan, z), (nan, nan), where
Sun, 18 Jul 2010 15:57:47 -0600, Charles R Harris wrote:
> On Sun, Jul 18, 2010 at 3:36 PM, Pauli Virtanen wrote:
[clip]
>> I suggest the following, aping the way the real nan works:
>>
>> - (z, nan), (nan, z), (nan, nan), where z is any fp value, are all
>> equivalent representations of "cnan",
On Sun, Jul 18, 2010 at 3:36 PM, Pauli Virtanen wrote:
> Hi,
>
> The current way of Numpy handles ordering of complex nan is not very well
> defined. We should attempt to clarify this for 1.5.0.
>
> For example, what should these return:
>
>r1 = np.maximum(complex(1, nan), complex(2, 0))
>
>
Hi,
The current way of Numpy handles ordering of complex nan is not very well
defined. We should attempt to clarify this for 1.5.0.
For example, what should these return:
r1 = np.maximum(complex(1, nan), complex(2, 0))
r2 = np.complex64(complex(1, nan)) < np.complex64(complex(2, 0))
o
