[Numpy-discussion] Rank-0 arrays - reprise
Charles R Harris
Sun Jan 6 11:53:47 CST 2013
On Sat, Jan 5, 2013 at 2:31 PM, Nathaniel Smith <firstname.lastname@example.org> wrote:
> On 5 Jan 2013 12:16, "Matthew Brett" <email@example.com> wrote:
> > Hi,
> > Following on from Nathaniel's explorations of the scalar - array
> > casting rules, some resources on rank-0 arrays.
> > The discussion that Nathaniel tracked down on "rank-0 arrays"; it also
> > makes reference to casting. The rank-0 arrays seem to have been one
> > way of solving the problem of maintaining array dtypes other than bool
> > / float / int:
> > Quoting from an email from Travis in that thread, replying to an email
> > from Tim Hochberg:
> > <quote>
> > > Frankly, I have no idea what the implimentation details would be, but
> > > could we get rid of rank-0 arrays altogether? I have always simply
> > > them strange and confusing... What are they really neccesary for
> > > (besides holding scalar values of different precision that standard
> > > Pyton scalars)?
> > With new coercion rules this becomes a possibility. Arguments against it
> > are that special rank-0 arrays behave as more consistent numbers with
> > rest of Numeric than Python scalars. In other words they have a length
> > and a shape and one can right N-dimensional code that works the same even
> > when the result is a scalar.
> > Another advantage of having a Numeric scalar is that we can control the
> > behavior of floating point operations better.
> > e.g.
> > if only Python scalars were available and sum(a) returned 0, then
> > 1 / sum(a) would behave as Python behaves (always raises error).
> > while with our own scalars
> > 1 / sum(a) could potentially behave however the user wanted.
> > </quote>
> > There seemed then to be some impetus to remove rank-0 arrays and
> > replace them with Python scalar types with the various numpy
> > precisions :
> > Travis' recent email hints at something that seems similar, but I
> > don't understand what he means:
> > <quote>
> > Don't create array-scalars. Instead, make the data-type object a
> > meta-type object whose instances are the items returned from NumPy
> > arrays. There is no need for a separate array-scalar object and in
> > fact it's confusing to the type-system. I understand that now. I
> > did not understand that 5 years ago.
> > </quote>
> > Travis - can you expand?
> Numpy has 3 partially overlapping concepts:
> A) scalars (what Travis calls "array scalars"): Things like "float64",
> "int32". These are ordinary Python classes; usually when you subscript
> an array, what you get back is an instance of one of these classes:
> In : a = np.array([1, 2, 3])
> In : a
> Out: 1
> In : type(a)
> Out: numpy.int64
> Note that even though they are called "array scalars", they have
> nothing to do with the actual ndarray type -- they are totally
> separate objects.
> B) dtypes: These are instances of class np.dtype. For every scalar
> type, there is a corresponding dtype object; plus you can create new
> dtype objects for things like record arrays (which correspond to
> scalars of type "np.void"; I don't really understand how void scalars
> work in detail):
While thinking about dtypes I started a post proposing that *all* arrays be
considered as special cases of void arrays. A void array is basically a
memory indexing construct combined with a view.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion