[PYTHON MATRIX-SIG] type coercion one more time

Hinsen Konrad hinsenk@ere.umontreal.ca
Thu, 25 Jan 1996 14:17:58 -0500

   like pi = array(3.1415926535, 'd').  In general, library functions
   should be expected to only return longs, doubles and complex doubles
   unless they are somehow "told otherwise".  This is just my opinion.

Library routines might need floats for the same reason they were
introduced: efficiency. And converting the result to double just
to conform to a specification is a bad idea if the caller wants
to go on using floats.

   The reason to not just make it float is that 3. * Array_l should
   produce an array of doubles, not of floats.  Also, if a function can
   accept either floats or doubles, 3. should be treated as a double.

I understand that, but don't see the point. Either I want double
precision, and then I want it under circumstances, or I am happy
with float, and then I start with float. For what application
might I possible want a number of unknown precision that is as
expensive as double, but can't be trusted to be more than float?
That's the worst of both types.

   I don't really see much difference between python scalars and
   constants.  The problem with both of them is that they have double

Not in implementation, but in use. Most constants occurring in real
programs can be represented by a float, but that is not true for an
arbitrary Python scalar that might be the result of a calculation. So
suppose (in principle; I don't want to do this!) that we add a type
"float" to Python and make all constants that do not exceed the
precision of "float" float constants (with automatic coercion to
double if the need arises), would you say that your problem is solved?

In fact, now that I think of it, this idea is not completely
unrealistic. A new type "float" could be seen as an implementation
alternative to "double" and wouldn't even have to be visible to the
programmer. I'll have to think a bit about this.

   types to be downcast to a lower precision.  (Or don't allow any
   automatic coercion of precision, but that original proposal seems to
   be an extremely unpopular idea based on some private responses I've

Given the choice between the two proposals, I very much prefer the
first one. An occasional exception (whis is easy to fix) is a lot
better than a loss in accuracy without warning.

Konrad Hinsen                     | E-Mail: hinsenk@ere.umontreal.ca
Departement de chimie             | Tel.: +1-514-343-6111 ext. 3953
Universite de Montreal            | Fax:  +1-514-343-7586
C.P. 6128, succ. Centre-Ville     | Deutsch/Esperanto/English/Nederlands/
Montreal (QC) H3C 3J7             | Francais (phase experimentale)

MATRIX-SIG  - SIG on Matrix Math for Python

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