[PYTHON MATRIX-SIG] casting and default types

[Jim Fulton, U.S. Geological Survey]

On Tue, 7 Nov 1995 16:02:56 -0500 
Hinsen Konrad said:
> 
>    Actually, this is not true.  There are some places where coersion
>    takes place automatically, but there are lot's of places where it
>    doesn't.  In the case of numbers, witness the float() and int()
>    functions.  Similarly, lists are not automatically converted to tuples
> 
> I can't imagine a need for float() and int() except in order to
> "downgrade" a number. In all mathematical operations where floats
> are required, I can just as well use ints. Lists and tuples are
> another problem, of course.
> 
> My point of view is that as far as coercion is concerned, matrices
> should behave just like scalars of the same type(s).

But what you are unwilling to believe is that scalars do not always
coerce automatically.

Try:

  spam = '0' * 20

and

  spam = '0' * 20.0

 
>    It's not just a matter of performance.  It is also a matter of
>    correctness in some cases.  
> 
> I don't understand. The choice is automatic coercion or none at all,
> i.e. throwing an exception for mixed-type operations. I don't see
> how one or the other can lead to a wrong result; it's either the
> correct result or no result.

No, another choice is generating an incorrect result.
 
> Of course there is some chance of making a mistake and not noticing
> it due to automatic coercion, but then you already have the same
> risk with scalars. Besides, I just can't think of a reasonable
> example...

OK, how about this:

  1 / 2 * 2

as opposed to:

  1 / 2.0 * 2

These two expressions generate different results.  If I wanted the
first algorithm, I would need to explicitly force 2.0 to be an
integer, but coersion has instead forced the first sub-expression to
be a floating-point expression.

There was discussion in the Python list a while back about problems
caused by a new feature that automatically coerced floating point
values passed to functions expecting integer arguments.  Guido even
expressed regret at being talked into adding the feature.  Check the
list archive for details.

Even if an error is raised, it may be raised far from where the
coersion that ultimately caused the error was done, making debugging
of the error difficult.

As I said in my other note, I object less to coersion of element types
that to coersion of ranks.
 
> Also, I'd expect users to be familiar with coercion. I haven't
> made a survey, but I'd claim that most languages have coercion
> between numerical types, similar to Python. That's certainly
> true for the languages most used for numerical work.

Again, user's familiar with Python should not expect coersion
everywhere.

User's familiar with Fortran should certianly not expect coersion
everywhere. 
 
>    I'd be much more in favor of having different kinds of matrices that
>    automagically coerce, if people really want this.
> 
> Which creates some question and probably a lot of confusion.
> What happens if coercing and non-coercing matrices are combined?
> What happens if a function written for one type of matrices
> is used with the other? How can the matrices be distinguished
> in output?

These are certainly valid points.  Of course, the situation would be
much worse with a global variable.

Jim

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

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