[PYTHON MATRIX-SIG] type coercion one more time

[Perry A. Stoll]

>>>>> "JH" == James Hugunin <jjh@Goldilocks.LCS.MIT.EDU> writes:
    JH> I've been working to design a stable version of automatic type
    JH> coercion that everybody (including myself) can be happy with.

Sounds good. I offer my support for continuing something similar to
the current scheme.

    JH> Only the following three automatic coercions are allowed:

    JH> 1) Any integer type can be coerced to a float, a double, a
    JH> complex float or a complex double.

Does 'any integer' type mean byte,short,integer? If so, OK.

    JH> 2) A float can only be coerced to a complex float.
    JH> 3) A double can only be coerced to a complex double.
    JH> Explanation:
    JH> The following type hierarchy is assumed:
    JH> INTEGER < FLOAT < COMPLEX
    JH> Within each level there are a number of possible precisions.

True, and it would be unrealistic to do arbitrary coercions. 

    JH> No automatic coercion will take place between these
    JH> precisions.

But there is no reason not to do coercion to a greater precision. See
below.

    JH> This remains completely consistent with the existing python
    JH> automatic type coercion.

To some extent. But there is no access in Python to most underlying C
numeric types, for good or bad. Good in most cases, bad in C/Fortran
interfacing cases. It seems like we're trying to add these types to
Python - this could be difficult.

    JH> a_l * a_d = a_d
    JH> a_f * a_l = a_f
    JH> a_f * a_d = TypeError Exception raised
    JH> a_d * a_D = a_D
    JH> a_1 * a_l = TypeError Exception raised

Raising exceptions in these circumstances seems a bit arbitrary. 

I think the source of your problem is the difference between Python's
floats (i.e. C doubles) and C floats. I don't know any way to specify
a C float in Python - does anyone? It seems the idealistic approach of
having only one floating point representation in Python is at odds
with peoples' desire to access C floats.

Also, I don't see how the scheme you outline above will solve your problem
   Array_f([1.0,2.0,3.0]) * 2.0 = Array_f([2.0,4.0,6.0]) 
since '2.0' is interpreted as a Python 'float', i.e. a C double. From
the scheme you propose above, this would raise an exception.  Assuming
it is too late to add '2.0f' to Python (or a better type specification
scheme as outlined earlier on this list), I can't think of a way to
get around this without explicitly doing an ungainly Matrix_f(2.0). Of 
course, if it matters this much, you could always do M_f = Matrix_f
and have M_f(2.0) scattered through your code. 

  The more I think about this (and since I'm thinking as I'm writing,
this is at the expense of conciseness - sorry!), the more I think your
situation is outside the Python norm and should really be viewed as
such.

  Although it may not solve your problem of C floats, I think it makes
more sense to allow conversion to any "higher" type, where "higher"
means higher in the list of types, i.e.
       b < s < i < l < f < d
Also:  (b,s,i,l,f) <= C
       (b,s,i,l,f,d,C) <= D

With the exception of the last bit, isn't this how the present (0.2)
release works?

  Also, I don't recall anyone presenting a list of 'nice' names for
the Matrix functions as Konrad has been advocating. I think having
these is a good idea; the type code that we have now has always seemed
somehow counter to (my view of) the Python 'do-it-the-Right-Way'
attitude.  If I actually list them all out here, maybe this will force
the issue and start some discussion. Comments on the following?

   Array_Char, Array_UChar
   Array_Short, Array_UShort
   Array_Integer,Array_UInteger,
   Array_Float, Array_Double,
   Array_FloatComplex, Array_DoubleComplex

'Unsigned' instead of 'U'? XArray instead of Array_X? BTW, is the C
multiarray object going to support all builtin numeric C types? Right
now, there is supported for both signed and unsigned bytes, but not
for unsigned shorts, ints, or longs - is that good enough? 

-Perry Stoll
  Research Associate, CSRL Advanced Telecommunications Research
  2-2 Hikaridai, Seika-cho Soraku-gun, Kyoto 619-02 JAPAN  
  FINGER: stoll@yoshino.atr.co.jp  EMAIL:  stoll@atr-sw.atr.co.jp
PGP 2.6 Key fingerprint = AF 56 5C D8 5F 78 BA FD  21 6E 2A 68 C4 55 9E B0





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

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