Am Dienstag, den 08.12.2009, 16:42 -0500 schrieb Raymond Toy:
> > Is it correct, that we have to cache one value of the constants %e, %
> > gamma, ... for every value of fpprec?
> >
> We don't have to. The way it works now is that we have one "large"
> precision value. If fpprec is smaller than this, we just round the
> large precision value to the desired precision. If fpprec is larger than
> that, a new value is computed and that is used.
You see, I do not know much about the bigfloat implementation.
> This is the source of the problem, though. There's no guarantee that
> rounding a 57 bit value to 56 bit value will give the same result as
> computing the 56 bit value.
> I implemented the hash table for fpe. From the testsuite, I see that
> there is one new failure: rtest_gamma 644 returns 3.750000000000002b-1
> instead of 3.75b-1. I have not investigated why the cached value
> causes this error. It could be caused by the computed value of %e is
> slightly off.
>
> >From the testsuite, the hash table has 75 entries, ranging from 56 bits
> to 1681 bits.
A lot of entries might be caused, because I have tried to check the
numerical algorithm of the beta and gamma functions over a greater range
of values for fpprec.
> I didn't compare the time, but since we compute new values of %e for
> each fpprec, we spend more time computing than just rounding a higher
> precision value. And a hash table lookup is probably quite a bit slower
> than what we have today. On the other hand, since we only have 75
> entries for the testsuite, we don't really recompute %e too often.
I think a typical application will use a fixed precision. Therefore, the
runtime might be no real problem.
> fppi has 75 entries, ranging from 56 to 467 bits, and fpgamma has 4
> entries, ranging from 56 to 428 bits.
> There is another approach that might work, but I suspect there are cases
> where it would also give incorrect results. We can continue to use the
> current algorithm, but if fpprec is too close to the max saved
> precision, we recompute %e to, say, twice fpprec and round that.
I think most important is to have a bigfloat arithmetic, which is
correct and consistent. The time I have implemented the bigfloat
algorithm for special functions I had no idea that we can get
inconsistencies because of the bigfloat implementation.
Dieter Kaiser