If a,b,c,d are all bfloats, or even if only one of a,c and one of
b,d are bfloats, then [a+c,b+d] is all you have to do. If they are
not, why would you round the endpoints of an interval, potentially
losing some of it?
Nevertheless.. If a, b,c,d are all double-floats or rationals or
integers or ....
then all you have to do is [bfloat(a+c), bfloat(b+d)]
But bfloats are not all the same, since they depend on fpprec.
Also what you are doing is actually "wrong" because of rounding issues,
if you want rigorous intervals.
Are you aware of the work by Chee Yap (at NYU) or other work on
geometric calculations, e.g.
at Berkeley, Jonathan Shewchuk?
And yes, iterated rational computations often make numerator and
denominator grow in size.
Finding a "small" approximation to a rational number is often possible,
though.
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
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>