[Numpy-discussion] Rank-0 arrays - reprise

Dag Sverre Seljebotn d.s.seljebotn@astro.uio...
Sun Jan 6 04:40:00 CST 2013


On 01/06/2013 11:16 AM, Nathaniel Smith wrote:
> On 6 Jan 2013 07:59, "Dag Sverre Seljebotn" <d.s.seljebotn@astro.uio.no
> <mailto:d.s.seljebotn@astro.uio.no>> wrote:
>  > Try to enumerate all the fundamentally different things (if you count
>  > memory use/running time) that can happen for ndarrays a, b, and
>  > arbitrary x here:
>  >
>  > a += b[x]
>  >
>  > That's already quite a lot, your proposal adds even more options. It's
>  > certainly a lot more complicated than str.
>
> I agree it's complicated, but all the complications and options already
> exist - they're just split across two similar-but-not-quite-identical
> sets of data types.
>
>  > To me it all sounds like a lot of rules introduced just to have the
>  > result of a[0] be "kind of a scalar" without actually choosing that
> option.
>
> Not sure what you mean here. We know that whatever object a[0] returns
> is going to have scalar behaviour. Right now we have two totally
> different implementations of scalars. I'm not suggesting changing any
> (or hardly any) existing behaviour, just that we switch which
> implementation of that behavior we use.

In that case, how about not changing += for READONLY but instead have a 
new ISSCALAR flag for that? I.e. semantics stay mostly as today, it's 
just about removing those 10,000 lines of C code.

> I actually wrote that email as kind of amusing exercise in "what
> if...?", but even after sleeping on it I'm still not thinking of any
> terrible downsides...

I should say that I am really happy with the direction it is taking though.

(I wish I understood why using Python floats and ints is so horrible 
though, but I've probably not written enough library NumPy code that 
needs to consider all ndims and dtypes, just final-end-user-code where 
the array vs. scalar distinction is more clear.)

Dag Sverre


More information about the NumPy-Discussion mailing list