[Numpy-discussion] Re: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #364 - 9 msgs

Greg Kochanski gpk at bell-labs.com
Wed Feb 9 12:25:00 CST 2000

"Andrew P. Mullhaupt" wrote:

> > It's most important that the rules be simple, and (preferably) close
> > to common languages.  I'd suggest C.
> That is a good example of a language which has a pretty weird history on
> this particular matter.

True.   The only real advantage of C is that so many people are
used to it.   Don't forget the human element.  FORTRAN would
also be a reasonable choice.

There's a big cost to learning a new language; if it gets too big,
people simply won't use Python.

> > Since automatic typecasting only buys a small improvement
> > in ease of use, I'd want to be extremely sure that it doesn't cause
> > many problems.
> Au contraire. It is a huge win. Try writing a "generic" function with six
> arguments which can sensibly be integers, or single or double precision
> variables. If you have to test variables to see what they are, then you have
> to essentially write a table driven typecaster. If, as in Fortran, you have
> to write different functions for different argument types then you have the
> dangerous programming practice of having several different pieces of code
> which do essentially the same computation.

While that's nice to say, it doesn't really translate completely to
A lot of functions don't make sense with arbitrary objects;
and some require subtle changes.

For instance, who wants a matrix inversion function that operates on
using integer division inside?

Lots of functions have DOUBLE_EPS or FLOAT_EPS embedded inside them.
One has to change the small number when you change the data type.

I'll grant you that running things with both doubles or floats is often
I'd be happy with automatic upcasting among them.
I'd be moderately happy with upcasting among the integers.
I really don't see any crying need to mix integers with floating point

I'd like some examples to make me believe that mixing ints and floats
is a 'huge win'.

More information about the Numpy-discussion mailing list