[Numpy-discussion] IEEE 754-2008 decimal floating point support
Wed Sep 8 15:50:52 CDT 2010
On 8 September 2010 16:33, Robert Kern <firstname.lastname@example.org> wrote:
> On Wed, Sep 8, 2010 at 15:10, Michael Gilbert
> <email@example.com> wrote:
>> On Wed, 8 Sep 2010 15:04:17 -0500, Robert Kern wrote:
>>> On Wed, Sep 8, 2010 at 14:44, Michael Gilbert
>>> <firstname.lastname@example.org> wrote:
>>> > Just wanted to say that numpy object arrays + decimal solved all of my
>>> > problems, which were all caused by the disconnect between decimal and
>>> > binary representation of floating point numbers.
>>> Are you sure? Unless if I'm failing to think through this properly,
>>> catastrophic cancellation for large numbers is an intrinsic property
>>> of fixed-precision floating point regardless of the base. decimal and
>>> mpmath both help with that problem because they have arbitrary
>> Here is an example:
>> >>> 0.3/3.0 - 0.1
>> >>> mpmath.mpf( '0.3' )/mpmath.mpf( '3.0' ) - mpmath.mpf( '0.1' )
>> >>> decimal.Decimal( '0.3' )/decimal.Decimal( '3.0' ) - decimal.Decimal ( '0.1' )
>> Decimal solves the problem; whereas mpmath doesn't.
> Okay, that's not an example of catastrophic cancellation, just a
> representation issue.
Indeed - and as I understand it the motivation for decimal numbers is
not that they suffer less from roundoff than binary, but because the
round-off they suffer from is better suited to (for example) financial
applications, where representing exact decimal numbers can be
If your problem is the fact of roundoff error, try using as your test
case, taking the square root of two and squaring it again. This will
suffer from the same sort of roundoff problems in decimal as binary.
> Robert Kern
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> -- Umberto Eco
> NumPy-Discussion mailing list
More information about the NumPy-Discussion