From: Tim H. <tim...@ie...> - 2002-09-16 19:38:06
|
From: "Konrad Hinsen" <hi...@cn...> > > Travis Oliphant wrote: > > Would they be recognised as scalars by Python? In particular, could you > > There is no "scalar" category in Python. New scalar datatypes would be > types with the same behaviour as the existing Python scalar types, but > different from the. That means that explicitly type-checking code would > not accept them, but everything else would. > > > use one as an index? Personally, this is what has bit me in the past: I > > At least up to Python 1.5, no, indices have to be of integer type. I > don't know if that condition was extended in later versions. In python 2.2 (I'm not sure about 2.0,2.1), you can subclass int and the resultant class can be used as an index. So I think this could be done. > > Frankly, I have no idea what the implimentation details would be, but > > could we get rid of rank-0 arrays altogether? I have always simply found > > If we introduce additional scalars, yes. Given that numarray has changed its coercion rules, is this still necessary? From http://stsdas.stsci.edu/numarray/Userguide.html: ----------start quote---------- ************* Type Coercion ************* In expressions involving only arrays, the normal coercion rules apply (i.e., the same as Numeric). However, the same rules do not apply to binary operations between arrays and Python scalars in certain cases. If the kind of number is the same for the array and scalar (e.g., both are integer types or both are float types), then the type of the output is determined by the precision of the array, not the scalar. Some examples will best illustrate: Scalar type * Array type Numeric result type numarray result type Int Int16 Int32 Int16 Int Int8 Int32 Int8 Float Int8 Float64 Float64 Float Float32 Float64 Float32 The change in the rules was made so that it would be easy to preserve the precision of arrays in expressions involving scalars. Previous solutions with Numeric were either quite awkward (using a function to create a rank-0 array from a scalar with the desired type) or surprising (the savespace attribute, that never allowed type coercion). The problem arises because Python has a limited selection of scalar types. This appears to be the best solution though it admittedy may surprise some who are used to the classical type coercion model. ----------end quote---------- > Whether or not we would want > to get rid of them is of course another question. Agreed. It's possible that rank zero arrays would be useful in certain unusual situations, although I can't think of any good examples. Regardless of that choice, if indexing never returns rank-0 arrays most people will never have to deal with them. -tim |
From: Perry G. <pe...@st...> - 2002-09-16 21:47:54
|
Konrad Hinsen writes: > "Chris Barker" <Chr...@no...> writes: > > > use one as an index? Personally, this is what has bit me in the past: I > > At least up to Python 1.5, no, indices have to be of integer type. I > don't know if that condition was extended in later versions. > > > could use A[3,2] as an index if A was type "Int" but not if it was > > "Int16" for example. > > Ehmmm... Are you sure that is the right example? The restriction is on > the type of the index, not on the type of the array. > I think Chris is referring to the fact that Numeric returns a rank-0 array for A[3,2] if A is of type Int16, and that value cannot be used as in index in Python sequences (at least for now; nothing technical prevents it from being implemented to accept object that have an __int__ method). This is the odd inconsistency Numeric has now. If A were a 1-d Int16 array then A[2] would not be a rank-0 array, nor is A[3,2] a rank-0 array if A is of type Int32 (apparently because a Python scalar type suffices). Why it gives rank-0 for 2-d and not 1-d I have no idea. > |
From: Travis O. <oli...@ee...> - 2002-09-16 22:50:52
|
> > Travis Oliphant wrote: > > > This is the gist of it. Basically you extend the Python scalars to > > include the single precision types (all the types Numeric supports). > > Would they be recognised as scalars by Python? In particular, could you > use one as an index? Personally, this is what has bit me in the past: I > could use A[3,2] as an index if A was type "Int" but not if it was > "Int16" for example. > > In any case, the type of A[3,2] should NOT depend on the precision of > the numbers stored in A. > > Frankly, I have no idea what the implimentation details would be, but > could we get rid of rank-0 arrays altogether? I have always simply found > them strange and confusing... What are they really neccesary for > (besides holding scalar values of different precision that standard > Pyton scalars)? With new coercion rules this becomes a possibility. Arguments against it are that special rank-0 arrays behave as more consistent numbers with the rest of Numeric than Python scalars. In other words they have a length and a shape and one can right N-dimensional code that works the same even when the result is a scalar. Another advantage of having a Numeric scalar is that we can control the behavior of floating point operations better. e.g. if only Python scalars were available and sum(a) returned 0, then 1 / sum(a) would behave as Python behaves (always raises error). while with our own scalars 1 / sum(a) could potentially behave however the user wanted. -Travis |
From: Pearu P. <pe...@ce...> - 2002-09-16 23:09:26
|
On Mon, 16 Sep 2002, Travis Oliphant wrote: > > Frankly, I have no idea what the implimentation details would be, but > > could we get rid of rank-0 arrays altogether? I have always simply found > > them strange and confusing... What are they really neccesary for > > (besides holding scalar values of different precision that standard > > Pyton scalars)? > > With new coercion rules this becomes a possibility. Arguments against it > are that special rank-0 arrays behave as more consistent numbers with the > rest of Numeric than Python scalars. In other words they have a length > and a shape and one can right N-dimensional code that works the same even > when the result is a scalar. In addition, rank-0 arrays are mutable while Python scalars are not. Mutability is sometimes useful (e.g. when emulating C or Fortran calls in Python) but often also evil due to its unpythonic side effect. Pearu |
From: Konrad H. <hi...@cn...> - 2002-09-13 20:33:07
|
Travis Oliphant <oli...@ee...> writes: > If we just implemented Python scalars for the other precisions then much > of this rank 0 array business would be solved as we could always return > the Python scalar rather than an array for rank 0 arrays. > > I believe Konrad made this suggestion many moons ago and I would agree Right. I still think this is the best solution in that it is the least confusing. If I remember correctly, the main objection was that implementing all those types was not as trivial as hoped, but I forgot the details (and it wasn't me who tried). Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hi...@cn... Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- |
From: Travis O. <oli...@ee...> - 2002-09-13 19:57:36
|
> > To restate the issue: there was a question about whether > an index to an array that identified a single element only > (i.e., not a slice, nor an incomplete index, e.g. x[3] where > x is two dimensional) should return a Python scalar or a > rank-0 array. Currently Numeric is inconsistent on this point. > One usually gets scalars, but on some occasions, rank-0 arrays > are returned. Good arguments are to be had for either alternative. > I think we should implement Python scalars for the other types and then eliminate rank-0 arrays completely. I could have a student do this in a few weeks if it was agreed on. -Travis Oliphant |