[PYTHON MATRIX-SIG] Type Coercion

[Paul. Dubois]

I hold these truths to be self-evident, your argument notwithstanding:
a. A PyFloat is a C double
   The fact that some of the Python API lets you convert one to a C
float easily doesn't change this.

b. It is a GOOD THING that you can count on the precision of a PyFloat.
    Writing portable code between platforms is easy with Python, since
even on 64 bit machines C doubles are implemented as 64 bit floats. (I
know that isn't for certain but as a practical truth, it is true).

c. It is a GOOD THING not to lose precision.
d. It is a GOOD THING not to get an exception.

The original design functioned perfectly, as far as I was concerned.

The change has been made because of a desire not to GAIN precision. This
is only a concern if you have a concern about space, really. (The time
penalty on most workstations for double vs. float is nowhere near 2).
So this means you must have a humongous amount of data. In which case,
Python is a lousy choice anyway, since it will make lots of temporaries
in the act of expression evaluation, while a nice Fortran routine won't.

In short, I'd argue that it is not a good idea to pervert the matrix
class in Python to satisfy a marginal need. 

But the alternative is unclean. The minute you find yourself proposing
that elements of an array are zero-d arrays you should realize the slope
has gotten too slippery.

I return to my previous horror example:

(1./3.) * a_float[i]
vs.
((1./3.) * a_float)[i]

Can you really stand for those to be different? Vectorize a loop and 
change the answer?
-- 
Paul F. Dubois, L-472				(510)-422-5426
Lawrence Livermore National Laboratory		FAX (510)-423-9969
Livermore, CA 94550				dubois1@llnl.gov
Consulting: PaulDubois@aol.com

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================