Does Python have a long floating data type please?
tim_one at email.msn.com
Sat Apr 1 22:24:37 CEST 2000
[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
More information about the Python-list