Does Python have a long floating data type please?
David C. Ullrich
ullrich at math.okstate.edu
Sat Apr 1 21:07:35 CEST 2000
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
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
> > ... - 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.
> things-that-aren't-obviously-wrong-ly y'rs - tim
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.)
More information about the Python-list