[Numpy-discussion] Nasty bug using pre-initialized arrays
Fri Jan 4 17:31:53 CST 2008
On Jan 4, 2008 3:28 PM, Scott Ransom <email@example.com> wrote:
> 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 .
> > 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.
This isn't a very compelling argument in this case. The concern the numarray
people were addressing was the upcasting of precision. However, there are
two related hierarchies in numpy, one is the kind of data, roughly: bool,
int, float, complex. Each kind has various precisions. The numarray folks
were concerned with avoiding upcasting of precision, not with avoiding
upcasting up kinds. And, I can't see much (any?) justification for allowing
automagic downcasting of kind, complex->float being the most egregious,
other than backwards compatibility. This is clearly an opportunity for
confusion and likely a magnet for bug. And, I've yet to see any useful
examples to support this behaviour. I imagine that their are some benifits,
but I doubt that they are compelling enough to justify the current
 I can't recall if this is the official terminology; I'm away from my
home computer at the moment and it's hard for me to check. The idea should
be clear however,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion