[PYTHON MATRIX-SIG] type coercion one more time

[James Hugunin]

   From: Guido van Rossum <guido@CNRI.Reston.VA.US>

   > One can imagine dividing each sample in a sound by 2, and then trying
   > to play it back and hearing garbage because it got automatically
   > converted to an array of longs during the division.

   I see your point, but I am uneasy with the solution.  Shouldn't there
   be a "divide in place" operation for this case that coerces constants
   the other way?  (I haven't followed all the details -- you may have it
   already or you may have a good reason for not having it.)

There should be a divide in place method, I just never bothered to add
it.  I'll try and remedy this before the beta release.

   I guess that you also don't check for overflow on such operations --
   suppose I multiply each sample by 2 and it doesn't fit...  This is
   also different than Python's own numeric operations, but again I can
   see the reason why (and I don't object in this case).

There are in fact two different modules which contain array math
operations.  umath and fast_umath.  These modules will actually define
the code used for things like a*4.  fast_umath will never check for
overflow for the obvious speed reasons.  umath is supposed to work as
much like regular python math as possible.  It checks for
divide-by-zero and for floating point overflows.  At the moment it
doesn't check for integer overflows, but it SHOULD, and it will as
soon as I get around to it.  I think having both of these modules is a
nice way to get "the best of both worlds".

   I guess I won't complain too loudly as long as you also have a way to
   coerce an array of shorts into an array of longs.

Anything can be cast to anything else, including shoving an array of
doubles into an array of bytes.  Of course, some casts are a better
idea than others...

   (BTW, on 64-bit machines, there are three relevant int sizes.  Do you
   support this?)

four actually, byte, short (2-byte), int (4-byte), and long (8-byte).
They're all there.


   > I do have one other possible set of rules that I would be happy with.
   > These are basically the same as the last post, except:
   > 
   > 4) Coercion to a higher precision is allowed within the main
   > groupings.
   > 
   > 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").

   Some examples, please?  Where else is coercion applied?  It does sound
   like it could be a good compromise.

See Perry's recent post for a good explanation of this proposal.

Examples:

array([1,2,3], 'f') * 2. -> array([1,2,3], 'f') # 2. is treated as a float here
array([1,2,3], 'l') * 2. -> array([1,2,3], 'l') # 2. is treated as a double here


   > I don't like this rule, but without it I think that it is too easy to
   > get bitten by python scalars when writing "real" code.

   Agreed.

   > Does this make sense?
   > 
   > Do people prefer this revised scheme?

   I'm not sure.  More input, please...

Well, I just saw your latest reply, so I don't think more input's
needed.  I'll send this anyway because the earlier comments should be
useful.

I think I'll give this thing another hour to settle down and then I'll
code up the new typecasting rules (I really love how quickly
discussion moves on this list).

-Jim



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

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