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