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

[Konrad Hinsen]

> > 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.
> 
> Does NumPy use the fpectl module?  I suppose not.  LLNL contribued that

No. Perhaps it should, but it doesn't make sense unless fpectl works
on a large number of platforms. I confess I have never looked at it. I
want my code to be portable, so I don't even consider using packages
that aren't.

> > 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.
> 
> You know I'm in general agreement with you on this one, but I have to draw a
> distinction here:  Guido thinks that 2/3 returning 0 was a design mistake,
> but not that math.sqrt(-1) raising an exception is a mistake.  Most Python
> users won't know what to do with a complex number, so it's "an error" to
> them.

Well, that would be a good occasion to learn about complex numbers! I
remember having learned about generalized inverses by using APL in
high school (in a very similar way: I was amazed that it could invert
non-square matrices), and that turned out to be very useful knowledge
later on. Perhaps that's a topic for the EDU-SIG...

Anyway, I don't care what math.sqrt(-1) does, but I would definitely
prefer Numeric.sqrt(-1) to return a complex result. And I think that
someone who uses NumPy has probably heard about complex numbers.


> I would like to view this in P3K (if not earlier) as being akin to
> 754 exceptions:  some people are delighted to have 1e300**2 return +Inf,
> while others want to see OverflowError instead, and still others want to see
> +Inf *and* have a sticky flag set saying "an overflow occurred".  We could
> treat f(x) (for f == sqrt and everything else) the same way wrt to a new
> ComplexResultFromNonComplexInputsError:  define "non-stop" complex results,
> let the user choose whether to do nonstop or raise an exception, and a
> supply a sticky flag saying whether or not any complex results were
> generated from non-complex inputs.

There is, however, one difference: in properly debugged production
code, there should be no overflow situations, so it doesn't matter
much how they are treated. Complex number can (do!) occur in
production code, but there could also be production code relying on
exceptions for sqrt(-1) (e.g. for input error checking). Therefore a
program using several libraries might be impossible to run with either
setting.

Since this concerns only the math module, I'd prefer to keep separate
module versions for the two cases, which can be used in parallel.

> > 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.
> 
> The current distinction between ints and longs (unbounded ints) should also
> get swallowed by this.  A way to get from here to there is especially
> irksome at the C API level, since, e.g., many C API functions pass Python
> ints as C longs directly.  A smaller number pass Python floats as C doubles
> directly.

I don't see the problem in that direction, it's rather C API functions
that *return* numbers in C data types that would be difficult to
adapt. But then, why should be C API not be allowed in P3K?

it's-wonderful-that-anything-may-be-changed-in-p3k'ly
  Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------