Robert Dodier wrote:
> On 1/26/08, S. Newhouse <sen1 at math.msu.edu> wrote:
>
>
>> For instance, if one defines the sum of intervals [a,b], [c,d] (with 0
>> < a < b and 0 < c < d) as
>> Iplus([a,b],[c,d])=[a+c, b+d],
>> then I would define
>> bIplus([a,b],[c,d]) = [bfloat(a)+bfloat(c), bfloat(b) + bfloat(d)]
>>
>
> (On a tangent: this shows a "destructuring bind" style of function definition
> that could be generally useful. Maxima can do something similar with
> pattern matching but expressed in Maxima's pattern matching language,
> it is quite a bit more obscure.)
>
>
>> It seems that I have to put in 'bfloat' in every representation of a
>> real number.
>>
>> Is there a way to declare all variables to be evaluated using 'bfloat'
>> without simply applying 'bfloat' to every occurrence?
>>
>
> Not that I know of. Another way to approach this is to define an
> operator, let's say "bf+", which applies bigfloat conversion to its
> arguments, e.g.
>
> nary ("bf+");
> "bf+" ([L]) := apply ("+", bfloat (L));
>
> 1 bf+ %pi bf+ %e;
> => 6.859874482048838b0
>
> bIplus (I1, I2) := [I1[1] bf+ I2[1], I1[2] bf+ I2[2]];
> bIplus ([%e, 10], [1, %pi]);
> => [3.718281828459045b0, 1.314159265358979b1]
>
> Writing "bf+" has the advantage that one can tell from reading
> an isolated expression (e.g. I1[2] bf+ I2[2]) that bigfloat conversion
> is applied to the arguments. If the conversion were controlled by
> some global variable, you would have to read the whole program
> and keep the global state in mind when reading each expression.
> (This is a general argument against global variables btw.)
>
> I wonder if you really need to enforce bigfloat arithmetic.
> Users might expect, extrapolating from Maxima's general treatment
> of integers and rationals, that an operation on exact intervals
> yields another exact interval.
>
> HTH
>
> Robert
> .
>
>
Thanks for the answer.
The ideas you mentioned may be very helpful.
On the need for bfloat, the issue is speed. I want to use maxima as an
aid to rigorous computation for Dynamical Systems (i.e., iteration of
maps and solutions of differential equations)
Consider the following.
(%i282) Nest(f, x, n) := block(for i thru n do x : f(x), val : x);
Evaluation took 0.00 seconds (0.00 elapsed) using 152 bytes.
(%o282) Nest(f, x, n) := block(for i thru n
do x : f(x), val : x)
(%i283) showtime: true;
Evaluation took 0.00 seconds (0.00 elapsed) using 56 bytes.
(%o283) true
(%i284) f(x):= 4*x*(1-x);
Evaluation took 0.00 seconds (0.00 elapsed) using 152 bytes.
(%o284) f(x) := 4 x (1 - x)
(%i285) ff(x):= bfloat(4)*bfloat(x)*(bfloat(1)-bfloat(x));
Evaluation took 0.00 seconds (0.00 elapsed) using 152 bytes.
(%o285) ff(x) := bf(4) bf(x)
(bf(1) - bf(x))
(%i286) fpprec: 50;
Evaluation took 0.00 seconds (0.00 elapsed) using 344 bytes.
(%o286) 50
(%i287) Nest(f,1/5,19)$
Evaluation took 38.75 seconds (38.75 elapsed) using 24.966 MB.
(%i288) Nest(ff,bfloat(.2),19)$
Evaluation took 0.01 seconds (0.00 elapsed) using 74.375 KB.
The function 'Nest(f,x,n)' computes the nth iterate of the point x for
the function f(x).
In rational arithmetic this is terribly slow--the 19th iterate for
f(x):= 4*x*(1-x) for x = 1/5 took almost 39 seconds.
My guess is that trying to do this on a 3d differential equation with an
extended precision 4th order Runge-Kutta (stepsize=.01, number of steps
100) would be unbearable.
But the bfloat version of 'Nest(f,.2,19)' took only 0.01 seconds even
with precision of 50 digits.
If anyone can tell me how to speed up the rational arithmetic version, I
would be delighted. I tried 'compile(all)' but it made no real
difference.
I wonder if the problem might be that in rational arithmetic repeated
many times, the rational numbers get very large numerators and
denominators. Would this be related to the slowness?
Thanks,
-sen