[Matrix-SIG] Numeric Nits

[Konrad Hinsen]

> 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.

That's why this would be a special-purpose *additional* float32 type.
New users wouldn't know about it and not use it, and those who do use
it are supposed to know why!

> 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

You'd cast it to a standard float32 first; that operation could be
implemented without copying the array data, so without serious memory
overhead.

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

Indeed. Again, new users are not supposed to mess around with this.

> 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?)

Scalar and array double are always treated in the same way, and I don't
think this should be changed.

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

Of course, but no more than any other proposition made so far.

> 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)

Fine, but that requires a change to the Python interpreter (implementation
of new data types plus special syntax for literals). Not impossible, but
I think Guido will want to see some very good arguments.

> (would it require syntax extensions which are not permitted to modules?)

Yes. Modules can implement new data types, but no new literals.
The Python parser would have to know that 2.0f is legal syntax, for
example.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------