[PYTHON MATRIX-SIG] type coercion one more time

[James Hugunin]

   From: hinsenk@ERE.UMontreal.CA (Hinsen Konrad)

      On the other hand, I see the other types as being used for cases where
      the programmer really wants to use a particular precision, ie. 2-byte
      integers for dealing with 16-bit sound data.  In a case like this it
      seems decidely unfriendly to automatically coerce to another
      precision.

   I wouldn't call it "decidedly unfriendly" (you can always avoid
   coercion by making sure that all variables have the same type), but it
   makes sense. It should also be noted that one of the main reasons to
   have float->double coercion in C is to make it possible to call
   functions written for double with float arguments. This problem does
   not exist in Python.

This all is irrelevant if we can agree on the part below.

      4) Coercion to a higher precision is allowed within the main
      groupings.

   What are "main groupings"?

int, float, complex (actually, string is also a grouping, but it
doesn't really pertain).

      5) The precision of a python scalar is allowed to change to match the
      other arguments (3.14 can be either a float or a double depending on
      which one is "desired").

   I don't like this rule for two reasons:
   1) You can lose precision without noticing it.

You can also lose precision by coercing a long to a double, but
nobody's complaining about that.  Also, the only place you can lose
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.

   2) It creates a subtle distinction between scalars and arrays of rank 0,
      which can only confuse users.

This is my own objection to the idea, but I think I have a way to make
this cleaner:

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.

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

Does this seem conceptually clean?

   On the other hand, I do see the problem you want to solve. It doesn't
   make any code easier to read if you have to convert every constant to
   a rank-0 float array. If I get an ingenious idea for solving this
   problem, I'll let you know immediately...

I'm finally starting to feel happy about this proposal, but ingenious
ideas are always welcome.

-Jim


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

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