Re: [Python-Dev] Decimal floats as default (was: discussion aboutPEP239 and 240)
Fredrik Johansson writes:
In either case, compatibility can be ensured by allowing both n-digit decimal and hardware binary precision for floats, settable via a float context.
Perhaps you can show me a design (or working code) that proves me wrong, but I don't believe that such a design could be made compatible with the existing Decimal module... certainly while continuing to maintain compatibility with the Cowlinshaw specification.
There is the alternative of providing decimal literals by using separate decimal and binary float base types
If, by this, you mean adding a "binary float context" modeled after the Decimal float context and providing access to the underlying FP flags and traps and generally enhancing the use of binary FP, then I think it's a great idea. It's probably impossible to write in a cross-platform manner (because C supplies support for binary FP but does not offer access to the flags and traps), but this is one of those few cases where it's worth using platform-and-compiler specific code. Of course, someone still has to step forward and offer to code it. -- Michael Chermside
On Mon, Jun 27, 2005, Michael Chermside wrote:
If, by this, you mean adding a "binary float context" modeled after the Decimal float context and providing access to the underlying FP flags and traps and generally enhancing the use of binary FP, then I think it's a great idea. It's probably impossible to write in a cross-platform manner (because C supplies support for binary FP but does not offer access to the flags and traps), but this is one of those few cases where it's worth using platform-and-compiler specific code.
Of course, someone still has to step forward and offer to code it.
...and document and maintain it. That's always been the sticky part, along with the requirement that this degrade gracefully when the platform-specific code doesn't exist. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng.
On 6/27/05, Michael Chermside
Fredrik Johansson writes:
In either case, compatibility can be ensured by allowing both n-digit decimal and hardware binary precision for floats, settable via a float context.
Perhaps you can show me a design (or working code) that proves me wrong, but I don't believe that such a design could be made compatible with the existing Decimal module... certainly while continuing to maintain compatibility with the Cowlinshaw specification.
Are you thinking of any particular problem?
There is the alternative of providing decimal literals by using separate decimal and binary float base types
If, by this, you mean adding a "binary float context" modeled after the Decimal float context and providing access to the underlying FP flags and traps and generally enhancing the use of binary FP, then I think it's a great idea.
The context (as I envision it) would not be just a "binary float context", but a universal float context that lets you choose between binary and decimal precision at run time. A context for Python's current float type would be a nice idea by itself, though.
It's probably impossible to write in a cross-platform manner (because C supplies support for binary FP but does not offer access to the flags and traps), but this is one of those few cases where it's worth using platform-and-compiler specific code.
I agree. --Fredrik
On 6/27/05, Fredrik Johansson
The context (as I envision it) would not be just a "binary float context", but a universal float context that lets you choose between binary and decimal precision at run time.
You mean something like this?
from __future__ import new_float_behaviour 1.1 1.1 import sys sys.float_context.binary = True 1.1 1.1000000000000001
I don't see why this couldn't be done. The default will be use decimal fp, and you can switch to binary fp if you need silicon-speed (unless, of course, you have decimal-on-silicon). In decimal mode, the context will be a full one, in binary mode, it's not mandatory to allow access to fpu flags, it could be just like now. . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Should I write a PEP? - Fredrik
Should I write a PEP?
No. Just let it evolve naturally. The next step is for a builtin C version. That will likely happen as soon as one of us has the time and inclination to write it. If that works out well, then writing decimal literals like 123d may be plausible. And, if that works out well too, then there would be some basis for Py3.0 using decimal as the default float. Raymond
participants (5)
-
Aahz -
Facundo Batista -
Fredrik Johansson -
Michael Chermside -
Raymond Hettinger