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

[Michael Haggerty]

> I think it would be simpler both to implement and to understand if
> there was just a 'd2' datatype that is above 'd' and if the
> promotion hierarchy is defined so that binary operations between
> 'f2' and 'd' get promoted to 'f2', but binary operations between
> 'f2' and 'd2' get promoted to 'd2'.

This proposal (discussed by several people) sounds like the best
direction for solving the promotion problem, but I think the
terminology is confusing.  (Imagine trying to explain it to a
beginner.)  Therefore I suggest a slight change:

Instead of creating new datatypes with weird places the type
hierarchy, let's rather define an additional attribute of the array
typecodes which might be called `force'.  So an array with typecode
ForcedFloat32 (I prefer a spelling such as 'f*') would be identical to
an array with typecode 'f' except that the result of ANY operation
involving such an array would be coerced to the same typecode, namely
'f*'.  Similarly, all of the other existing typecodes would have
forced versions.  Any non-forced object that appears in an expression
with a forced object would be ruthlessly cast to the forced data
object's type, even if that requires a downcast or a conversion from
floating point to integer.  An expression involving two incompatible
forced objects would raise an exception.

To typecast a forced object into another type (including casts into
the non-forced version of the same type) would require an explicit
conversion such as with array():

    >>> a = arange(5, typecode='f*')
    >>> b = 2.0 * a
    >>> print b
    array([  0.,   2.,   4.,   6.,   8.], 'f*')
    >>> print array(b, 'd')
    array([  0.,   2.,   4.,   6.,   8.])

This proposal probably doesn't differ in effect from the previous one,
but I think it is conceptually simpler to understand and to explain.

Michael

--
Michael Haggerty
mhagger@blizzard.harvard.edu