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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4