[PYTHON MATRIX-SIG] type coercion one more time
Thu, 25 Jan 96 16:26:37 EST
Paul's and Konrad's arguments make me think that this whole type
coercion issue needs to be reevaluated before mistakenly commiting to
a bad strategy. I still want to release a 0.30 version tommorrow,
hopefully with stable naming conventions and API. The only things I
have left to do are packaging and tests on our alphas and pentiums for
some semblance of portability. Unfortunately, this release will have
an interim API that is highly unlikely to be the final solution, oh
I have been busy giving talks and attending meetings, etc., and had a
hard time plowing through all this carefully. If I understand the latest
idea with respect to precision, I think I can live with it but I don't
like it. It would violate the principle of least surprise.
I agree with this completely. This is why I proposed the awkward
Array_f*3.14 -> Exception solution. For me having this go to an
Array_d is not what I am expecting.
It essentially changes the precision of the scalars in Python iff they
get involved with doing something with Array_f's. I don't like
exceptions in languages. Exceptions lead to weird behavior.
For example, we all agree it is a Good Thing that x[i] is a scalar not
an array of size 1. But in fact this means that
(1./3.) * x[i] is not ((1./3.) * x)[i] if x is Array_f.
This is a great example of where my newer proposal has problems.
I agree it is nice to go fast but let's not go too fast.
I thought the "generic" stuff was off track. Everybody who writes
anything that handles Arrays has enough trouble without one more type to
I don't think this will actually impact people much beyond the sort of
problems you mention above. It's mainly just to keep things
reasonably clean conceptually.
Jim, what you need to do in your own work can be pretty much solved with
a little literal function:
so that you just always say lit(2.) rather than 2. You have to train
yourself to do this in the places where it matters, true, but otherwise
you are just going to make the rest of us miserable.
Well, the last thing I want to do is to make anybody miserable, but I
still think that I have a reasonable point here.
With the current (0.20) type coercion semantics, python scalars are
completely useless in an equation unless you want to work with longs,
doubles, or complex doubles. The new proposal, while slightly
strange, at least gives a reasonable meaning to python scalars for
Just to make things concrete, I picked a reasonable simple function
that I use a lot of the time. Do you find this readable?
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: email@example.com
administrivia to: firstname.lastname@example.org