Does Python have a long floating data type please?

[Tim Peters]

[David C. Ullrich]
> ...
>     Exactly what convinced me that a real should be a pair of
> longRationals (giving a lower bound and an upper bound for the
> "real" value). At least the basic arithmetic operations seem
> simple enough that a person could get them right, and they'd be
> obviously right.
> ...
> class real:
>   def __init__(self, l, u):
>     self.l = l
>     self.u = u
>   def __add__(self, other):
>     return real(self.l + other.l, self.u + other.u)
>
> Pretty exciting stuff. (Well, the correctness of __mul__
> might not be obvious at one glance like __add__ above,
> because of what happens if l < 0 and u > 0, but it should
> nonetheless be extremely trivial to verify.)

Yes, this is what I'd do too -- you'll get something you can trust much
faster this way.  Jurjen's real.py can be viewed as space optimizations of
this approach, first representing the interval by a midpoint and a delta,
then fixing the delta at 1 by introducing a power-of-2 scale factor instead.
The details are tricky, though!

Something all "interval" approaches have problems with is systematic
pessimism.  The classic example is

    y = x - x

y is in fact exactly 0 no matter how fuzzy x is, but straightforward
interval subtraction yields a result centered at 0 and twice as fuzzy as x.

In your original post you had a milder example, x*x.  This has got to be >=
0 in actuality, but if x is e.g. [-2, 2] then straightforward interval
multiplication yields [-4, 4] instead of [0, 4].

Because of this pessimism, some simple series approaches to building
functions (like exp and sin etc) out of the arithmetic primitives can fail
to converge; this is where proofs start to get hard despite (or perhaps
because of <wink>) the simplicity of the primitives.

doable-in-the-end-but-it-doesn't-stay-trivial-ly y'rs  - tim