On Sat, Apr 30, 2011 at 3:11 AM, Guido van Rossum <gu...@python.org> wrote: > Decimal, for that reason, has a context that lets one specify > different behaviors when a NaN is produced. Would it make sense to add > a float context that also lets one specify what should happen? That > could include returning Inf for 1.0/0.0 (for experts), or raising > exceptions when NaNs are produced (for the numerically naive like > myself). > > I could see a downside too, e.g. the correctness of code that > passingly uses floats might be affected by the context settings. > There's also the question of whether the float context should affect > int operations; floats vs. ints is another can of worms since (in > Python 3) we attempt to tie them together through 1/2 == 0.5, but ints > have a much larger range than floats.
Given that we delegate most float() behaviour to the underlying CPU and C libraries (and then the math module tries to cope with any cross-platform discrepancies), introducing context handling isn't easy, and would likely harm the current speed advantage that floats hold over the decimal module. We decided that losing the speed advantage of native integers was worthwhile in order to better unify the semantics of int and long for Py3k, but both the speed differential and the semantic gap between float() and decimal.Decimal() are significantly larger. However, I did find Terry's suggestion of using the warnings module to report some of the floating point corner cases that currently silently produce unexpected results to be an interesting one. If those operations issued a FloatWarning, then users could either silence them or turn them into errors as desired. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
