I've updated the PEP to conform to what I think is the best hybrid solution propsed and that is to implement a tree of PythonTypes in C whose leaves are (to the Python user) new rank-0 arrays. This is more work to implement (but I don't think a great deal of work see below), and I think it will lead to the best results under our current constraints. Internally, the PyArray_Type will still deal with rank-0 arrays (in fact the new Python scalars will be converted to them internally rather than special-case a bunch of code). I don't think we should try to solve the general number-hierchy in Python at this time. We will implement the array-number hierarchy only. If this leads to others getting interested in the general problem, then that may come, but now we have to focus on our objective of getting the arrayobject accepted into Python. Note that these new rank-0 Python scalars will be simple, have the same methods and attributes as Python arrays (likely-implemented once in the GenericArrType by converting the object to a rank-0 array). Also, they will inherit (multiple-inheritance is possible in C) from the appropriate Python Type where an exact-match is available. -Travis
Travis Oliphant <oliphant@ee.byu.edu> writes:
I've updated the PEP to conform to what I think is the best hybrid solution propsed and that is to implement a tree of PythonTypes in C whose leaves are (to the Python user) new rank-0 arrays.
For the purpose of differentiating between basic and advanced indexing, are rank 0 arrays considered scalars or arrays? Does their presence among indices trigger advanced indexing? For sequence behaviour len, indexing and iteration should work consistently, i.e., "a[i] for i in xrange(len(a))" and "x for x in a" should identically generate the contents of a. Currently indexing and iteration occur along the first dimension, which for rank 0 arrays does not exist. I understand that there is no burning desire to completely switch to Matlab-style one-dimensional indexing. The alternatives are then giving rank 0 arrays exceptional semantics inconsistent with other arrays or raising an exception if len or iteration is applied to a rank 0 array. Without exceptional semantics the only index expression that makes sense is a[()]. I would favor consistency here and raise an exception but there is one matter that raises some doubt: do programs expect that if __len__ and __iter__ exist they will not fail? Converting scalars back to arrays: they should be rank 0. Rank 1 would be Matlabish nonsense, except that Matlab is even more nonsensical and uses rank 2. But when is such conversion needed? If it is only for operations with other arrays then broadcasting is likely to occur immediately. -- Timo Korvola <URL:http://www.iki.fi/tkorvola>
"Travis" == Travis Oliphant <oliphant@ee.byu.edu> writes:
Travis> I've updated the PEP to conform to what I think is the Travis> best hybrid solution propsed and that is to implement a Travis> tree of PythonTypes in C whose leaves are (to the Python Travis> user) new rank-0 arrays. This is more work to implement Travis> (but I don't think a great deal of work see below), and I Travis> think it will lead to the best results under our current Travis> constraints. Hi Travis, One issue I didn't see addressed in the PEP is the handling of special values for floating point numbers, eg inf and nan. Will Numeric3 be able to handle something like
nan = float('nan') inf = float('inf') n.array([inf, nan])
or otherwise support these special values? A common request I get in matplotlib is to be able to handle float arrays with nan, but I've hesitated tackling this because of a lack of consistent support for these values in python, Numeric and numarray. In this particular example, Numeric 23.7 raises a traceback in the repr pipeline, and numarray appears to work properly. Apologies if I missed a discussion of this topic already on this list -- searching for nan in my mail reader keeps matching Fernando, and inf matches listinfo.... Thanks, JDH
participants (3)
-
John Hunter -
Timo Korvola -
Travis Oliphant