Paul Zimmermann writes:
Of course you can add say 100 guard bits, then the probability to get an
incorrect rounding is about 2^-100...
You're joking, but this was sort-of my thinking when designing mpf!
--
Torbjörn
Please encrypt, key id 0xC8601622
_
Dear Frank,
> If I ever need correct rounding with GMP (I don't ATM), I think
> I could add 0.5e-P, then (like above) multiply by 1eP, convert to
> mpz_t and insert the decimal point manually.
since there is no documented error bound in the mpf computations,
there is no chance that this wi
Marco Bodrato wrote:
> Il 2021-08-25 05:54 Frank Heckenbach ha scritto:
> > mpf_get_str seems to round incorrectly sometimes.
> > In this test program, the digits around 809 are "...244594553...",
> > so it should round to "...244595", but it outputs "...244594".
>
> Here, your report says that y
Ciao,
Il 2021-08-25 05:54 Frank Heckenbach ha scritto:
mpf_get_str seems to round incorrectly sometimes.
In this test program, the digits around 809 are "...244594553...",
so it should round to "...244595", but it outputs "...244594".
Here, your report says that you expected a "rounded" result
Marc Glisse wrote:
> if you care about correct rounding, I would recommend you use MPFR
> instead.
This seems to be a bigger change which I'd like to avoid, at least
for now. (I use GMP in several programs, some of which have grown
over many years ...)
Actually, what I wanted is truncation, not
On Wed, 25 Aug 2021, Frank Heckenbach wrote:
mpf_get_str seems to round incorrectly sometimes.
In this test program, the digits around 809 are "...244594553...",
so it should round to "...244595", but it outputs "...244594".
Hello,
if you care about correct rounding, I would recommend you use
mpf_get_str seems to round incorrectly sometimes.
In this test program, the digits around 809 are "...244594553...",
so it should round to "...244595", but it outputs "...244594".
#include
#include
int main (void)
{
mpf_t pi;
mp_exp_t e;
mpf_set_default_prec (1); // much more than su