In article <[EMAIL PROTECTED]>, Grant Edwards <[EMAIL PROTECTED]> writes: |> > |> > Now, I should like to improve this, but there are two problems. The |> > first is political, and is whether it would be acceptable in Python to |> > restore the semantics that were standard up until about 1980 in the |> > numerical programming area. I.e. one where anything that is numerically |> > undefined or at a singularity which can deliver more than one value is |> > an error state (e.g. raises an an exception or returns a NaN). |> |> That's fine as long as the behavior is selectable. I almost |> always want a quiet NaN.
That is one of the two modes that I regard as respectable. However, because integer arithmetic doesn't have a NaN value (which could be fixed, in Python), anything that returns an integer has to raise an exception. On that matter, division by zero and several other currently trapped numeric errors could be modified to return NaN for people like you (if the option were selected, of course). I will take a look at adding NaN to integers, but that is a much hairier hack - and it STILL doesn't deal with comparisons (which can be done only in a purely functional programming language). |> While you're at it, the pickle modules need to be fixed so they |> support NaN and Inf. ;) Yup. On my list :-) Regards, Nick Maclaren. -- http://mail.python.org/mailman/listinfo/python-list