# [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

Sun, 15 Oct 2000 21:04:27 +0200

```> I've come to Python from MATLAB for numerics, and I really appreciated
> MATLAB's way of handling all this. I don't think MATLAB has true 754

MATLAB is fine for simple interactive data processing, and its
behaviour is adapted to this task. I don't think anyone would use
MATLAB for developing complex algorithms, its programming language
isn't strong enough for that. Python is, so complex algorithms have to
be considered as well. And for that kind of application, continuing a
calculation with Infs and NaNs is a debugging nightmare.

> I have not yet heard a decent response to the question of what to do
> when a single value in a large array is bad, and causes an exception.

I'd like to have at least the option of raising an exception in that
case. Note that this is not what NumPy does today.

> >> sqrt(-1)
> ans =
>	   0 + 1.0000i
>
> Hey! I like that! Python is dynamic, why can't we just get the actual
> answer to sqrt(-1), without using cmath, that always returns a complex ?

For the same reason that makes 2/3 return zero instead of a float
division result. Like C or Fortran, Python treats integers, floats,
and complex numbers as different data types. And the return type of a
function should depend only on the types, but not the values, of its
parameters (for consistency, not because of any implementational
limitation). So sqrt(a) for a of type float can either always return a
float (math, Numeric) and crash for negative arguments, or always
return a complex (cmath).

The "right" solution, in my opinion, would be to have a single
"number" type of which integers, float, and complex numbers are simply
different internal representations. But such a change cannot be
introduced without breaking a lot of code.