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