The arrayobject for scipy.base seems to be working. Currently the Numeric3 CVS tree is using the "old-style" ufuncs modified with new code for the newly added types. It should be quite functionable now for the brave at heart. I'm now working on modifying the ufunc object for scipy.base. These are the changes I'm working on: 1) a thread-specific? context that allows "buffer-size" level trapping of errors and retrieving of flags set. Similar to the decimal.context specification, but it uses the floating point sticky bits to implement. 2) implementation of buffers so that type-conversions (and byteswapping and alignment if necessary) never creates temporaries larger than the buffer-size (the buffer-size is user settable). 3) a reworking of the general N-dimensional loop to use array iterators with optimizations applied for contiguous arrays. 4) Alteration of coercion rules so that scalars (i.e. rank-0 arrays) do not dictate coercion rules Also, change so that certain mixed-type operations are computed in larger type for both. Most of this is pretty straightforward. But, I do have one addiitonal question. Do the new array scalars count as "non-coercing" scalars (i.e. like the Python scalars), or do they cause coercion? My preference is that ALL scalars (anything that becomes 0-dimensional arrays internally) cause only "kind-casting" (i.e. int to float, float to complex, etc.) but not "type-casting" -Travis
On Apr 5, 2005, at 5:26 PM, Travis Oliphant wrote:
The arrayobject for scipy.base seems to be working. Currently the Numeric3 CVS tree is using the "old-style" ufuncs modified with new code for the newly added types. It should be quite functionable now for the brave at heart.
I'm now working on modifying the ufunc object for scipy.base.
These are the changes I'm working on:
1) a thread-specific? context that allows "buffer-size" level trapping of errors and retrieving of flags set. Similar to the decimal.context specification, but it uses the floating point sticky bits to implement.
2) implementation of buffers so that type-conversions (and byteswapping and alignment if necessary) never creates temporaries larger than the buffer-size (the buffer-size is user settable).
3) a reworking of the general N-dimensional loop to use array iterators with optimizations applied for contiguous arrays.
4) Alteration of coercion rules so that scalars (i.e. rank-0 arrays) do not dictate coercion rules Also, change so that certain mixed-type operations are computed in larger type for both.
Most of this is pretty straightforward. But, I do have one addiitonal question. Do the new array scalars count as "non-coercing" scalars (i.e. like the Python scalars), or do they cause coercion?
My preference is that ALL scalars (anything that becomes 0-dimensional arrays internally) cause only "kind-casting" (i.e. int to float, float to complex, etc.) but not "type-casting"
Seems reasonable. One could argue that since they have their own precision that normal coercion rules should apply, but so long as Python scalar literals don't, having different coercion rules for what look like scalars taken from arrays than for python scalars is bound to lead to great confusion. So I agree. Perry
participants (2)
-
Perry Greenfield
-
Travis Oliphant