Does Python have a long floating data type please?

David C. Ullrich ullrich at math.okstate.edu
Sun Apr 2 15:43:47 EDT 2000


Tim Peters wrote:

> [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.
> > ...
> [Stuff that Tim claimed he'd find exciting snipped]
>
> 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.

    I guess I shouldn't say I don't see the problem until I've done it.
Exp is increasing, so it seems easy: given that a <= x <= b what
follows about exp(x) is exactly exp(a) <= exp(x) <= exp(b); you
calculate exp(a) and exp(b) as precisely as needed, insert the
appropriate fudge factor and there you are. (If you're talking about
summing the power series with an interval-valued argument I
see why that would be tricky. But I don't see why you'd do that.)

    Sin is not quite so simple, since it's not increasing. But given
a <= x <= b what follows about sin(x) is A <= sin(x) <= B,
where each of A and B is either sin(a), sin(b), 1, or -1, depending
on where the multiples of Pi lie wrt the interval [a,b]. Seems
like a few cases to consider (and we have to start by getting
(a divmod pi) to the appropriate precision) but I don't see
any big problems.

    Easy to say, I guess.

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




More information about the Python-list mailing list