Does Python have a long floating data type please?

[David C. Ullrich]

Tim Peters wrote:

> [David C. Ullrich, notes some examples of dubious intervals computed
>  by Jurjen N.E. Bos's real.py module]

    One was dubious, the other was wrong. (Never mind...)

> Yes, and I've posted others in the past (including cases that aren't near
> 0).

    Musta been before my time.

> Jurjen used a very clever storage-efficient representation, but didn't
> record correspondingly clever correctness arguments <wink>.  Sometimes it's
> easy to see a bug, sometimes I have no idea what he was thinking.
>
> This isn't unusual for these kinds of pkgs, though!  Correctness proofs can
> be quite involved.  Valérie Ménissier-Morain has submitted a 59-page article
> giving correctness proofs for her version of this quest, available somewhere
> more-or-less obvious under
>
>     http://pauillac.inria.fr/~menissier/
>
> > ... - at this point I decided to give up on real.py and make my own.
>
> Which is why there are a dozen packages like this out in the world each with
> its own set of unique subtle bugs <wink>.  Since this stuff runs too slow to
> use for truly large problems anyway, I never understood why pkgs try to
> conserve storage at the cost of vastly subtler reasoning.

    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.

> Guess it's seen
> as a challenge.
>
> personally-more-excited-by-things-that-are-obviously-right-than-by-
>     things-that-aren't-obviously-wrong-ly y'rs  - tim

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.)

DU