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 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). 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 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).
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] 0. 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. -tim
------------------------------------------------------- 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. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
On 19.02.2005, at 22:45, Travis Oliphant wrote:
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
-1 I consider this a kludge that might be acceptable if no other solution is politically doable, but not a desirable feature.
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 provided that 1) a special long double type is created 2) the type promotion rules handle scalars in some reasonable way
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
+1 It works well enough in practice.
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 This is still my first choice. Konrad.
I'm going to refrain from a numerical rating but rather add a few comments and questions
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
A minor question, in this and other cases where rank-0 is being used, what will repr show? For example, if I do:
x = arange(2) x[0]
do I get '0' or 'array(0)' ? 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. 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 lot more than I have.
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.
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
I've never really liked this behavior.
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).
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)? Perry
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
participants (4)
-
konrad.hinsen＠laposte.net -
Perry Greenfield -
Tim Hochberg -
Travis Oliphant