|
From: Travis O. <oli...@ee...> - 2006-02-14 00:33:19
|
Francesc Altet wrote: >Hi Travis, > >I've finished a series of tests on your recent new implementation of >unicode types in NumPy. They discovered a couple of issues in Numpy: one >is clearly a bug that show up in UCS2 builds (see the patch attached). >The other, well, it is not clear to me if it is a bug or not: > > Thanks very much for these tests... They are very, very useful. I recently realized that the getitem material must make copies for misaligned data because the convert to UCS2 functions expect aligned data (on Solaris anyway it would cause a segfault). You caught an obvious mistake in that code. >>>>ia1=numpy.array([1]) >>>>type(ia1) >>>> >>>> ><type 'numpy.ndarray'> > > >>>>type(ia1.view()) >>>> >>>> ><type 'numpy.ndarray'> > >However, for 0-dimensional arrays: > > > >>>ia0=numpy.array(1) >>>type(ia0) >>> >>> Francesc Altet wrote: >>>type(ia0.view()) >>> >>> <type 'int32scalar'> !!!!!! Do you think the next this is a bug or a feature? My opinion is that it is a bug, but maybe I'm wrong. In fact, this has a very bad effect on unicode objects in UCS2 interpreters: Almost all of the methods right now, return scalars instead of 0-dimensional arrays on purpose. This was intentional because 0-dimensional arrays were not supposed to be handed around in Python. But, we were unable to completely eliminate them at this point. So, I suppose, though there are a select few methods that should not automatically convert 0-dimensional arrays to the equivalent scalar. .copy() is one of them *already changed* .view() is probably another *should be changed*. If you can think of other methods that should not return scalars instead of 0-dimensional arrays, post it. -Travis |