[Numpy-discussion] Rank-0 arrays - reprise

[Dag Sverre Seljebotn]

On 01/06/2013 10:41 AM, Sebastian Berg wrote:
> On Sun, 2013-01-06 at 08:58 +0100, Dag Sverre Seljebotn wrote:
>> On 01/05/2013 10:31 PM, Nathaniel Smith 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.
>>>>
>
> <snip>
>
>>> Q: Yeah. I mean, I remember that seemed weird when I first learned
>>> Python, but when have you ever felt the Python was really missing a
>>> "character" type like C has?
>>
>> str is immutable which makes this a lot easier to deal with without
>> getting confused. So basically you have:
>>
>> a[0:1] # read-write view
>> a[[0]] # read-write copy
>> a[0] # read-only view
>>
>> AND, += are allowed on all read-only arrays, they just transparently
>> create a copy instead of doing the operation in-place.
>>
>> 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.
>>
>> 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.
>>
>
> Yes, but I don't think there is an option to making the elements of an
> array being immutable. Firstly if you switch normal python code to numpy
> code you suddenly get numpy data types spilled into your code, and
> mutable objects are simply very different (also true for code updating
> to this new version). Do you expect:
>
> array = np.zeros(10, dtype=np.intp)
> b = arr[5]
> while condition:
>      # might change the array?!
>      b += 1
> # This would not be possible and break:
> dictionary[b] = b**2
>
> Because mutable objects are not hashable which important considering
> that dictionaries are a very central data type, making an element return
> mutable would be a bad idea.

Indeed, this would be completely crazy.

I should have been more precise: I like the proposal, but also believe 
the additional complexity introduced have significant costs that must be 
considered.

  a) Making += behave differently for readonly arrays should be 
carefully considered. If I have a 10 GB read-only array, I prefer an 
error to a copy for +=. (One could use an ISSCALAR flag instead that 
only affected +=...)

  b) Things seems simpler since "indexing away the last index" is no 
longer a special case, it is always true for a.ndim > 0 that "a[i]" is a 
new array such that

a[i].ndim == a.ndim - 1

But in exchange, a new special-case is introduced since READONLY is only 
set when ndim becomes 0, so it doesn't really help with the learning 
curve IMO.

In some ways I believe the "scalar-indexing" special case is simpler for 
newcomers to understand, and is what people already assume, and that a 
"readonly-indexing" special case is more complicated. It's dangerous to 
have a library which people only use correctly by accident, so to speak, 
it's much better if what people think they see is how things are.

(With respect to arr[5] returning a good old Python scalar for floats 
and ints -- Travis' example from 2002 is division, and at least that 
example is much less serious now with the introduction of the // 
operator in Python.)

> One could argue about structured datatypes, but maybe then it should be
> a datatype property whether its mutable or not, and even then the
> element should probably be a copy (though I did not check what happens
> here right now).

Elements from arrays with structured dtypes are already mutable (*and*, 
at least until recently, could still be used as dict keys...). This was 
discussed on the list a couple of months back I think.

Dag Sverre

>
>> BUT I should read up on that thread you posted on why that won't work,
>> didn't have time yet...
>>
>> Dag Sverre
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>