# [Maxima] adding floats. a peculiarity, and a proposal

Richard Fateman fateman
Fri Sep 1 09:36:48 CDT 2006

```

> -----Original Message-----
> From: Stavros Macrakis [mailto:macrakis at gmail.com]
> Sent: Friday, September 01, 2006 7:20 AM
> To: Richard Fateman
> Cc: maxima
> Subject: Re: [Maxima] adding floats. a peculiarity, and a proposal
>
> >  ALL user floating-point format input be stored as
> infinitely precise
> > rational numbers until there is a first conversion to
> something that
> > is used computationally, at which point it is converted to the
> > appropriate type, precision, etc.
>
> I am not sure exactly what you are proposing.  If 0.1b0 is
> stored as 1/10 but converted when it is "used
> computationally", then you will get the same results as
> above, but with a large overhead:
> sum(0.1b0,i,1,10) would have to convert 1/10 to binary form 10 times.

There are areas that would have to be figured out, maybe heuristically

0.1b0 with default fpprec is ((BIGFLOAT SIMP 56) 57646075230342349 -3)
My proposal would change that to either ((BIGFLOAT SIMP 56 1/10)
57646075230342349 -3)
or maybe ((rat simp ((BIGFLOAT SIMP 56) 57646075230342349 -3) )  1 10)

if you added two of these together, it could be done as exact rationals or
as bigfloats.

>
> And what is the "appropriate type"?  The value of fpprec at
> the time of conversion?

If one of these is added to a double, then double would be the type.
If one is added to a rational, then rational would be the type.

> That is the current semantics for
> converting exact numbers to bfloats.

>
> Perhaps the proposal is that bfloat constants be represented
> as decimal floating-point?  That certainly has advantages
> supports base-10 internally in some cases at least.

Bfloat can do base-10 by setting one flag. It uses this to do binary to
decimal
conversion.
>
> As for the specific examples of sum, I wonder if they would
> come out differently if we fixed the known bugs in bfloat?
> There are documented cases where bfloat does not round correctly.

I'm not sure these are bugs in rounding or bugs in one's expectation. I
wrote the bfloat
stuff, but looking at fpround makes my head swim.

>
> By the way, I was curious to see what would happen to
> computation times if I used exact (rational) arithmetic
> (sum(1/i,i,1,N)) vs.
> bfloat (sum(1.0b0/i,i,1,N)).  I expected that with the growth
> in denominator size, rational would quickly become much more
> expensive than bfloat (default fpprec=16).  In fact, the
> crossover is at about N=10000.
>
>                -s
>

```