When you are ready to try some truly pathological numbers, I stumbled across a program that uses them.  They are decimal calculations that display rounding error 600+ digits away.  Find the code at https://gist.github.com/vernondcole/11066121

C:>jython phi.py
Phi is 624 digits long, 1.618...24292
The 1st identity is 2.9 and 621 more "9"s then 8
The 2nd identity is 3.0 and 620 more "0"s then 2
Equal? False
The difference is= 2.2E-622

Date: Wed, 09 Apr 2014 08:02:32 +0100
From: Jeff Allen <ja.py@farowl.co.uk>
Subject: Re: [Jython-dev] Test failures for float
To: Jython Developers <jython-dev@lists.sourceforge.net>
Message-ID: <5344F088.8040007@farowl.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I wrote a pretty good replacement for core.stringlib.Formatter, based on
java.text.DecimalFormatter. It agrees with CPython for all "reasonable"
precisions, that is to say up to 16 significant figures, and no-one has
had to take the log of anything. It can provide float.__str__ and
float.__repr__ more cleanly than at present too.

But it fails tests like this: AssertionError:
'10000000000000000000000000000000000000000000000000' !=
'9999999999999999464902769475481793196872414789632'

I haven't come across any cases where the problem is that the actual
float value is different (considered at the bit-level using
float.hex()); it's all on the output formatting. CPython appears to give
us the exact value -- there is always a finite answer, though it may
have a thousand digits. DecimalFormatter, which is at bottom just
Double.toString(), gives us just enough digits to differ from the next
float bit pattern.

Experiments with BigDecimal suggest I can get exact conformance by that
route and it seems worth the attempt, so I'm going that way.

Jeff