[Numpy-discussion] Nasty bug using pre-initialized arrays

[Scott Ransom]

On Friday 04 January 2008 05:17:56 pm Stuart Brorson wrote:
> >> I realize NumPy != Matlab, but I'd wager that most users would
> >> think that this is the natural behavior......
> >
> > Well, that behavior won't happen. We won't mutate the dtype of the
> > array because of assignment. Matlab has copy(-on-write) semantics
> > for things like slices while we have view semantics. We can't
> > safely do the reallocation of memory [1].
>
> That's fair enough.  But then I think NumPy should consistently
> typecheck all assignmetns and throw an exception if the user attempts
> an assignment which looses information.
>
> If you point me to a file where assignments are done (particularly
> from array elements to array elements) I can see if I can figure out
> how to fix it & then submit a patch.  But I won't promise anything!
> My brain hurts already after analyzing this "feature".....   :-)

There is a long history in numeric/numarray/numpy about this "feature".  
And for many of us, it really is a feature -- it prevents the automatic 
upcasting of arrays, which is very important if your arrays are huge 
(i.e. comparable in size to your system memory).

For instance in astronomy, where very large 16-bit integer or 32-bit 
float images or data-cubes are common, if you upcast your 32-bit floats 
accidentally because you are doing double precision math (i.e. the 
default in Python) near them, that can cause the program to swap out or 
die horribly.  In fact, this exact example is one of the reasons why 
the Space Telescope people initially developed numarray.  numpy has 
kept that model.  I agree, though, that when using very mixed types 
(i.e. complex and ints, for example), the results can be confusing.

Scott

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sransom at nrao.edu             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989