[PYTHON MATRIX-SIG] type coercion one more time

[James Hugunin]

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
well.


   Sender: dubois@llnl.gov

   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
   look for.

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:
   def lit(d):
	   return Array_f(d)

   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
other types.

Just to make things concrete, I picked a reasonable simple function
that I use a lot of the time.  Do you find this readable?

def hamming(x):
	return lit(0.54)-lit(0.46)*cos(lit(2*pi)*x/lit(len(x)-1))

vs.

def hamming(x):
	return 0.54-0.46*cos(2*pi*x/(len(x)-1))


-Jim

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

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