[Matrix-SIG] Numeric Nits--a slightly different proposal

[Craig Schardt]

At 08:20 AM 7/16/99 , Rick White wrote:
>Maybe you missed the original reason for these types, which is that any
>operations with Python scalars lead to promotions, effectively making
>the lower types (Float32, Int16, etc.) nearly useless except for input
>and output.  For example, if x is a Float32 array, then (x+1) is a
>Float64 array.  Adding Numeric types that do not get promoted in
>operations with scalars puts the programmer back in control.
>
>At that point, in my opinion, the least surprising behavior would be
>for promotions to occur in the normal way within the hierarchy.  Only
>operations with other forced arrays would lead to promotion, and so the
>programmer can easily control that (just like you do when you write
>non-Numeric Python.)

I was in favor of the extended casting hierarchy approach discussed earlier 
on this list. It was my understanding that the non-promotable types were 
designed to defeat the default upcasting. As such, any casting between 
'Forced' types should cast to the smallest (ie. most restrictive) of the 
two types. An operation between a ForcedFloat32 and a ForcedInt16 should 
return a ForcedInt16. After declaring a type Forced, it is the 
responsibility of the programmer to specify that the restriction can be 
loosened by an explicit cast.

The current Python hierarchy is:

         Int16 -> Int32 -> Float32 -> Float64

I suggest that the Forced be the reverse of the normal hierarchy:

         ForcedFloat64 -> ForcedFloat32 -> ForcedInt32 -> ForcedInt16

This system respects the size restrictions that the user places on their 
data. A user accepts the potential loss of accuracy when they declare 
something Forced, in exchange, the type system should guarantee that the 
Forced declaration is respected.

IMNSHO, the main reason for using the Forced types is to eliminate the 
memory bloat which occurs when small types are upcast. If I declare an 
array ForcedInt16, I want it to stay that way for the sake of conserving 
memory. If I pass it to a function I don't want the function to be able to 
override my type declaration and return an array cast to ForcedFloat32. If 
I wanted a ForcedFloat32 I would have declared it that way from the start.

If the Forced types follow the normal promotion order, then the Forced type 
system is just a hack to get around the python core's upcasting of scalars 
to Float64. The reverse promotion order may be more surprising, but it is 
also more in line with the original need for such a secondary type system, 
and it gives the programmer more control over data-types and memory usage 
during numerical computations.

But will any of this fix the integer division nit?
-craig.