[Numpy-discussion] Poll on a Rank-0 arrays: please give +1, -1, or 0

[Travis Oliphant]

Perry Greenfield wrote:

>I'm going to refrain from a numerical rating but rather add a few comments
>and questions
>  
>
Great, works just as well.

>do I get '0' or 'array(0)' ?
>  
>
I'm thinking '0' here since we want "array" scalars to look and act like 
Python scalars.

>I suppose the former is fine if rank-0 is usable in every way as a scalar
>and no one really needs to know the difference, but I troubles me a bit to
>hide this fact (with repr) if it isn't quite the same.
>  
>
Well, I suppose repr could show something else (i.e. how you would 
create one) while str could print it like a scalar.  

>Along those lines (for this case and the last) I worry that there are
>potential gotchas that haven't been discovered yet. How confident are you
>that there aren't any in trying to integrate rank-0 with Python scalars and
>their usage. It may be one of those things that is hard to know unless the
>work of trying to implement it is actually done. You've thought about this a
>
Well, there may always be potential gotchas.  But, I'm extremely 
confident that the new Python scalars will work seemlessly with array 
objects.  The will work in Python as scalars pretty much anyplace a 
subtype is allowed (PyInt_Check will return True, for example).   There 
are a few places in Python where for performance reasons, exact integers 
are special-cased.  The new array-type scalars would not benefit from 
those places in the code.

>>2) Rank-0 arrays are never returned from uarray operations (unless using
>>asarray on a scalar), and when a rank-0 array naturally appears in the
>>calculation, an appropriate Python scalar is returned (note that this
>>would lose precision for long doubles unless a new Python object was
>>created).
>>
>>    
>>
>As Konrad mentions, as long as there is some means of handling long doubles,
>I find scalars perfectly acceptable. I tend to think that is what most user
>assume they are getting.
>  
>
Then, I think solution 4 is the right one....

>>    
>>
>Sounds good if there are no gotchas but may be a lot of work (coding and
>political). Any performance issues regarding rank-0 vs scalars? Will users
>pay a penalty for using rank-0 in scalar-like expressions (no apparent array
>usage other than the rank-0 values)?
>  
>
I see three performance issues:

1) the parts of Python that special-case for exact integer arguments.

2) if array scalars are internally converted to rank-0 arrays and then 
passed through the ufunc machinery to implement all operations (which 
will be the default implementation), then this will be a bit slower (not 
sure how much slower) --- especially after special casing for contiguous 
arguments in the ufunc code (PEP to come later).   

3) If the type hierarchy is too deep, then a few more pointer 
dereferences would be needed to find the function to call. 

Power users looking for a speed boost on scalar operations would have to 
manually get an exact Python integer.   So, I don't think array scalars 
would "take over" every need for a scalar, but they would be scalars 
that act as a smooth intermediary between N-d arrays *and* Python scalars.

I think by introducing this parallel set of array scalars we decrease 
the political issues.  We are not asking non-numeric Python users to 
change all beloved integers to something more generic.   We are just 
introducing a bunch of "array-behaved" scalar objects that will also 
inherit from Python builtin types where appropriate.


-Travis