[Matrix-SIG] Numeric Nits

[Christos Siopis]

On Wed, 23 Jun 1999, Scott M. Ransom wrote:

> The more I think about it, maybe Konrad et al. are correct with the
> solution of declaring certain 'f' arrays higher in the cast hierarchy
> than doubles.  These arrays would never be up-cast to type double.  This
> would allow the use of the same simple syntax (i.e. arange(3.0, typecode
> = 'f') * 2.0  gives array([ 0.,  2.,  4.],'f') _not_ array([ 0.,  2., 
> 4.]).

However, just to play devil's advocate, suppose a new user *does* know
that Python natively only supports doubles and that upcasting is the
normal behavior --then s/he might be confused that the result is a float.
Alternatively, what if one *does* want the result of arange(3.0, typecode
= 'f') * 2.0 to be a double? (ok here one could simply use 'd' instead of
'f' but that could be an issue in more complex expressions, where one
might be forced to convert the whole expression back to double). 

Furthermore, if types such as bytes, shorts, etc. are also introduced,
figuring out the resulting type might get messy, e.g. would

array([0,2,4],'Int32') * 2

be an Int32 (because Int64 is the Python default, in analogy with Float32
and Float64)?

How about:

array([0,2,4],'Int32') + array([9,10,11],'Int64')

or even

array([0.,2.,4.],'Float32') + array([9.,10.,11.],'Float64')

(i.e., would the 'f'-arrays-higher-in-the-case-hierarchy apply only with
respect to scalar doubles or also with respect to array doubles?)

Even if such rules could be clearly set out, would they not make
Numeric programming more complicated and error-prone?


I was thinking that using single-letter appendices at the end of numbers
to designate non-default types might serve as a solution. E.g.:

2.4f , 2.4e03f : float (single precision)
2.4d == 2.4 , 2.4e03 : double (Python default)
32b : 8-bit integer
32s : 16-bit integer
32i : 32-bit integer
32  : 64-bit integer (Python default)

The advantage of this is that we need not change upcasting rules and no
old codes would break. Simply, new code that wants to take advantage of
this facility might do so. E.g.,

arange(3.0, typecode = 'f') * 2.0

would be a double, as it is now. To get a float, use instead:

arange(3.0, typecode = 'f') * 2.0f

and so on.

Please do not jump on me if this is impossible to implement for some
reason that has to do with Python's innards (I am new to all this) :) 
(would it require syntax extensions which are not permitted to modules?)
but it seems to me that, if something like this is doable, it would be a
nice compromise between clarity, adding new features and not breaking old
code. 

Christos Siopis