[Numpy-discussion] Rank-0 arrays - reprise

[Charles R Harris]

On Sat, Jan 5, 2013 at 2:31 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On 5 Jan 2013 12:16, "Matthew Brett" <matthew.brett at gmail.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:
> >
> >
> http://mail.scipy.org/pipermail/numpy-discussion/2002-September/001612.html
> >
> > Quoting from an email from Travis in that thread, replying to an email
> > from Tim Hochberg:
> >
> >
> http://mail.scipy.org/pipermail/numpy-discussion/2002-September/001647.html
> >
> > <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
> found
> > > 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
> the
> > 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 :
> >
> >
> http://mail.scipy.org/pipermail/numpy-discussion/2002-September/013983.html
> >
> > Travis' recent email hints at something that seems similar, but I
> > don't understand what he means:
> >
> >
> http://mail.scipy.org/pipermail/numpy-discussion/2012-December/064795.html
> >
> > <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 [1]: a = np.array([1, 2, 3])
>
> In [2]: a[0]
> Out[2]: 1
>
> In [3]: type(a[0])
> Out[3]: 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.

<snip>

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130106/849f34d6/attachment.html>