[Python-Dev] Not-a-Number
Antoine Pitrou
solipsis at pitrou.net
Sat Apr 30 12:37:22 CEST 2011
On Sat, 30 Apr 2011 08:02:33 +0100
Mark Dickinson <dickinsm at gmail.com> wrote:
> On Fri, Apr 29, 2011 at 2:18 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> > Taking a step back from all this, why does Python allow
> > NaNs to arise from computations *at all*?
>
> History, I think. There's a c.l.p. message from Tim Peters somewhere
> saying something along the lines that he'd love to make (e.g.,) 1e300
> * 1e300 raise an exception instead of producing an infinity, but dare
> not for fear of the resulting outcry from people who use the current
> behaviour. Apologies if I've misrepresented what he actually
> said---I'm failing to find the exact message at the moment.
>
> If it weren't for backwards compatibility, I'd love to see Python
> raise exceptions instead of producing IEEE special values: IOW, to
> act as though the divide-by-zero, overflow and invalid_operation FP
> signals all produce an exception. As a bonus, perhaps there could be
> a mode that allowed 'nonstop' arithmetic, under which infinities and
> nans were produced as per IEEE 754:
>
> with math.non_stop_arithmetic():
> ...
>
> But this is python-ideas territory.
I would much prefer this idea than the idea of making NaNs
non-orderable. It would break code, but at least it would break
in less unexpected and annoying ways.
Regards
Antoine.
More information about the Python-Dev
mailing list