question about the use of bfloat



On Jan 26, 2008 1:16 PM, S. Newhouse <sen1 at math.msu.edu> wrote:

> >> Is there a way to declare all variables to be evaluated using 'bfloat'
> >> without simply applying 'bfloat' to every occurrence?
>

bfloat has nothing to do with variables or evaluation; it is a function that
converts *values* to their bfloat equivalent. In Maxima (unlike some
languages), assigning a value to a variable, or getting the value of a
variable, never converts the value.

On the other hand, Maxima *does* have the concept of type contagion for
numbers.  For all arithmetic operations Op, Op(rational,float) => float;
Op(rational,bfloat) => bfloat; Op(float,bfloat) => bfloat. The glitch in
this scheme is that *symbolic* constants like %pi and %e and exact numeric
expressions like sqrt(2) do not participate in this scheme -- though
arguably any operation between an exact and an approximate quantity should
result in an approximate one, e.g. sqrt(2)+1.0 => 2.414.

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

A few comments on your code:


> Nest(f, x, n) := block(for i thru n do x : f(x), val : x);


Why does this function modify the global variable "val"? Is this a
return-value convention in some other language?  Also, in Maxima, the
iteration variable is local.  So you can simply write

   Nest(f, x, n) := ( for i thru n do x : f(x), x );



> (%i284) f(x):= 4*x*(1-x);
> (%i285) ff(x):= bfloat(4)*bfloat(x)*(bfloat(1)-bfloat(x));
>

(%i287) Nest(f,1/5,19)$
> Evaluation took 38.75 seconds (38.75 elapsed) using 24.966 MB.
>

Yes, this is giving you the *exact* result. It is the price of precision...


> (%i288) Nest(ff,bfloat(.2),19)$
> Evaluation took 0.01 seconds (0.00 elapsed) using 74.375 KB.


Try Nest(f,bfloat(1/5),19).  This will be as fast as your ff.

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?
>

Yes.

         -s