[PYTHON MATRIX-SIG] type coercion one more time
Perry A. Stoll
Fri, 26 Jan 1996 01:09:53 +0900
>>>>> "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> 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
But there is no reason not to do coercion to a greater precision. See
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
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)
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?
'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?
Research Associate, CSRL Advanced Telecommunications Research
2-2 Hikaridai, Seika-cho Soraku-gun, Kyoto 619-02 JAPAN
FINGER: firstname.lastname@example.org EMAIL: email@example.com
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: firstname.lastname@example.org
administrivia to: email@example.com