[Numpy-discussion] Poll on a Rank-0 arrays: please give +1, -1, or 0
Travis Oliphant
oliphant at ee.byu.edu
Sun Feb 20 14:24:11 CST 2005
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
More information about the Numpy-discussion
mailing list