Re: [Numpy-discussion] PEP 209: Multi-dimensional Arrays

Some random PEP talk.

...

...

...

...

"PB" == Paul Barrett writes:

PB> 2. Additional array types PB> Numeric 1 has 11 defined types: char, ubyte, sbyte, short, int, PB> long, float, double, cfloat, cdouble, and object. There are no PB> ushort, uint, or ulong types, nor are there more complex types PB> such as a bit type which is of use to some fields of science and PB> possibly for implementing masked-arrays. True: I would have had a much easier life with a ushort type. PB> Its relation to the other types is defined when the C-extension PB> module for that type is imported. The corresponding Python code PB> is: >> Int32.astype[Real64] = Real64 I understand this is to be done by the Int32 C extension module. But how does it know about Real64? PB> Attributes: PB> .name: e.g. "Int32", "Float64", etc. PB> .typecode: e.g. 'i', 'f', etc. PB> (for backward compatibility) .typecode() is a method now. PB> .size (in bytes): e.g. 4, 8, etc. "element size?"

...

add.register('add', (Int32, Int32, Int32), cfunc-add)

Typo: cfunc-add is an expression, not an identifier. An implementation of a (Int32, Float32, Float32) add is possible and desirable as mentioned earlier in the document. Which C module is going to declare such a combination? PB> asstring(): create string from array Not "tostring" like now? PB> 4. ArrayView PB> This class is similar to the Array class except that the reshape PB> and flat methods will raise exceptions, since non-contiguous PB> arrays cannot be reshaped or flattened using just pointer and PB> step-size information. This was completely unclear to me until here. I must say I find this a strange way of handling things. I haven't looked into implementation details, but wouldn't it feel more natural if an Array would just be the "data", and an ArrayView would contain the dimensions and strides. Completely separated. One would always need a pair, but more than one ArrayView could use the same Array. PB> a. _ufunc: PB> 1. Does slicing syntax default to copy or view behavior? Numeric 1 uses slicing for view, and a method for copy. "Feeling" compatible with core python would require copy on rhs, and view on lhs of an assignment. Is that distinction possible? If copy is the default for slicing, how would one make a view? PB> 2. Does item syntax default to copy or view behavior? view. PB> Yet, c[i] can be considered just a shorthand for c[i,:] which PB> would imply copy behavior assuming slicing syntax returns a copy. If you reason that way, then c is just a shorthand for c[...] too. PB> 3. How is scalar coercion implemented? PB> Python has fewer numeric types than Numeric which can cause PB> coercion problems. For example when multiplying a Python scalar PB> of type float and a Numeric array of type float, the Numeric array PB> is converted to a double, since the Python float type is actually PB> a double. This is often not the desired behavior, since the PB> Numeric array will be doubled in size which is likely to be PB> annoying, particularly for very large arrays. Sure. That is handled reasonably well by the current Numeric 1. To extend this, I'd like to comment that I have never really understood the philosophy of taking the largest type for coercion in all languages. Being a scientist, I have learned that when you multiply a very accurate number with a very approximate number, your result is going to be very approximate, not very accurate! It would thus be more logical to have Float32*Float64 return a Float32! PB> In a future version of Python, the behavior of integer division PB> will change. The operands will be converted to floats, so the PB> result will be a float. If we implement the proposed scalar PB> coercion rules where arrays have precedence over Python scalars, PB> then dividing an array by an integer will return an integer array PB> and will not be consistent with a future version of Python which PB> would return an array of type double. Scientific programmers are PB> familiar with the distinction between integer and float-point PB> division, so should Numeric 2 continue with this behavior? Numeric 2 should be as compatible as reasonably possible with core python. But my question is: how would we do integer division of arrays? A ufunc for which no operator shortcut exists? PB> 7. How are numerical errors handled (IEEE floating-point errors in PB> particular)? I am developing my code on Linux and IRIX. I have seen that where Numeric code on Linux runs fine, the same code on IRIX may "core dump" on a FPE (e.g. arctan2(0,0)). That difference should be avoided. PB> a. Print a message of the most severe error, leaving it to PB> the user to locate the errors. What is the most severe error? PB> c. Minimall UFunc class: Typo: Minimal? Regards, Rob Hooft -- ===== rob@hooft.net http://www.hooft.net/people/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! =========