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
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
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"
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,
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
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
