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.