[Numpy-discussion] Poll on a Rank-0 arrays: please give +1, -1, or 0
tim.hochberg at cox.net
Sat Feb 19 14:53:23 CST 2005
Travis Oliphant wrote:
> We need to get some opinions regarding the recent discussion on rank-0
> arrays. Please give your vote +1 (like), -1 (hate), or 0 (don't
> care) for **each** of the following possibilities. Feel free to
> clarify your vote if you need to.
> 1) Rank-0 arrays are always returned from uarray operations, Python
> scalars available on request only. (*If* arrayobject get's into
> Python core, Guido has agreed to let rank-0 integer arrays be used as
> index variables). Rank-0 arrays are made to resmbe scalar of
[Something appears to be scrambled here, but I think I get the gist of it]
This seems most self consistent option. It will, however, break some
unknown amount of code since I'm sure some stuff relys on Python int /
float behaviour that will be somewhat different than rank-0 array
behaviour. One example is multiplying two rank-0 integers won't
overflow into longs as would two python integers. I think it will also
feel odd: people expect scalars when they index a rank one array.
Even though Guido agreed to let rank-0 arrays work as index variables,
the index issue will still be problematic. Even assuming that
arrayobject makes it into the core, it won't, and shouldn't happen, till
we have some experience as a community using and polishing it. In the
meantime, indexing won't work, which will make it harder to use. Meaning
a smaller community and less likelihood that it goes into the core. It's
chicken and an egg problem.
> 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).
-1 unless a new object is created. -0 in that case.
> 3) The current compromise is continued and for some types a Python
> scalar is returned, while for other types a rank-0 array is returned
0. This is a bit of a mess, but has the advantage of backwards
compatibility. Also we have a fair amount of experience with it and know
that it works at least fairly well.
> 4) Rank-0 arrays are made equivalent to Python scalars and a new
> Python scalar for each fundamental data type supported by uarray is
> constructed (rank-0 arrays would still probably be used internally,
> but users would not have to know this). The new Python-scalars would
> inherit from an existing Python scalar where appropriate and would
> have the same attributes and methods of uarrays (very likely at least
> initially they would be seemlessly converted to rank-0 arrays when
> "mixed" operations occur).
+1 assuming the details can be worked out. I think this will feel more
natural in acutal use than the first option. It also should avoid the
indexing problem that hamper that option.
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion