Dieter Kaiser wrote:
> Am Dienstag, den 08.12.2009, 07:27 -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.
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.
> If this is the case I can not imagine that we need to store a lot of
> values. We have the standard value fpprec = 56 and some extra values
> because of extra digits we use in some calculations. A user who change
> the value of fpprec will need the same amount of extra values for his
> choice of fpprec.
>
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.
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.
fppi has 75 entries, ranging from 56 to 467 bits, and fpgamma has 4
entries, ranging from 56 to 428 bits.
> The only code I knew which might changes the value of fpprec more than
> once is the the code for the hypergeometric functions. I think fpprec
> can be stepwise doubled up to a value of fpprec=1000. But this is done
> in four steps.
>
> Perhaps, it is possible to flush the cache, when a user changes the
> value of fpprec very often.
>
I didn't consider that, but it's easy enough to add the function to
clear the cache if desired.
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.
Ray