[Maxima] adding floats. a peculiarity, and a proposal
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)
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
> 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
> (and disadvantages). And I believe that bfloat already
> 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
> 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.
More information about the Maxima