[PYTHON MATRIX-SIG] type coercion one more time

James Hugunin jjh@Goldilocks.LCS.MIT.EDU
Thu, 25 Jan 96 14:01:34 EST


   From: hinsenk@ere.umontreal.ca (Hinsen Konrad)

      precision is in a python scalar so I'm not really worried about this.
      Admittedly, array([1,2,3], 'f')*3.1415926535 might cause you to lose
      some precision in pi, but I assume that this is what most people would
      want.

   In this case, with an explicit constant, I agree that most people
   would probably want a float result. But suppose you are using a
   library function that does float calculations and returns a float
   array as a result. You call this function and multiply its result with
   a double that you have obtained from some complicated high-precision
   calculation. Wouldn't you be both surprised and annoyed if the
   result were a float array?

I'd be tempted to say that if you have a high-precision double that
you're really concerned about then you'll just have to say something
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.

      Add three more names, "GenericInt", "GenericFloat", "GenericComplex"
      (or whatever).

      Now I can say a = array(1, "GenericFloat") and this means that in
      general a will behave as a double, but it can be coerced downwards to
      a float if required.

   Why not make it float from the beginning? If you can't rely on the
   extra precision being conserved, you could just as well forget about
   it. I don't see much use for "unknown precision" numbers.

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.

      Now, 3.14 -> array(3.14, "GenericFloat").

      Does this seem conceptually clean?

   Conceptually clean, yes. But it is a somewhat weird concept.

Weird I can agree with.

   Let me start another approach to the problem: do you see a need for
   "downcasting" anything else than constants? In that case one could
   think about some special treatment for them.

I don't really see much difference between python scalars and
constants.  The problem with both of them is that they have double
precision no matter what.  I think that it's important to allow these
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
gotten).

-Jim



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

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