Re: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #364 - 9 msgs
"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 practice. 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 integers, 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 useful. 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 numbers.
I'd like some examples to make me believe that mixing ints and floats is a 'huge win'.