[Numpy-discussion] Assigning complex values to a real array

Dag Sverre Seljebotn dagss at student.matnat.uio.no
Wed Dec 9 04:18:57 EST 2009


Pauli Virtanen wrote:
> ti, 2009-12-08 kello 22:26 -0800, Dr. Phillip M. Feldman kirjoitti:
>   
>> Darren Dale wrote:
>>     
>>> On Sat, Mar 7, 2009 at 5:18 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>>       
>>>> On Sat, Mar 7, 2009 at 04:10, Stéfan van der Walt <stefan at sun.ac.za>
>>>> wrote:
>>>>         
>>>>> 2009/3/7 Robert Kern <robert.kern at gmail.com>:
>>>>>           
>>>>>> In [5]: z = zeros(3, int)
>>>>>>
>>>>>> In [6]: z[1] = 1.5
>>>>>>
>>>>>> In [7]: z
>>>>>> Out[7]: array([0, 1, 0])
>>>>>>             
>>>>> Blind moment, sorry.  So, what is your take -- should this kind of
>>>>> thing pass silently?
>>>>>           
>>>> Downcasting data is a necessary operation sometimes. We explicitly
>>>> made a choice a long time ago to allow this.
>>>>         
>
> I'd think that downcasting is different from dropping the imaginary
> part. Also, I doubt a bit that there is a large body of correct code
> relying on the implicit behavior. This kind of assertions should of
> course be checked experimentally -- make the complex downcast an error,
> and check a few prominent software packages.
>
> An alternative to an exception would be to make complex numbers with
> nonzero imaginary parts to cast to *nan*. This would, however, likely
> lead to errors difficult to track.
>
> Another alternative would be to raise an error only if the imaginary
> part is non-zero. This requires some additional checking in some places
> where no checking is usually made.
>
> At least I tend to use .real or real() to explicitly take the real part.
> In interactive use, it occasionally is convenient to have the real part
> taken "automatically", but sometimes this leads to problems inside
> Matplotlib.
>
> Nevertheless, I can't really regard dropping the imaginary part a
> significant issue. I've sometimes bumped into problems because of it,
> and it would have been nice to catch them earlier, though. (As an
> example, scipy.interpolate.interp1d some time ago silently dropped the
> imaginary part -- not nice.)
>   
FWIW, +1. And if nothing is done, there should at least be big fat red 
warnings prominently in the documentation.

(Knowing that imaginary parts can in some situations be dropped without 
warning makes me rather uneasy...at least now I know to look out for it 
and double check the dtypes on the lhs.)

Dag Sverre



More information about the NumPy-Discussion mailing list