Re: convert mpf t to double with rounding-modes defined by ieee754 usenett at
Mon Aug 1 12:16:29 CEST 2005

> > I don't want to say that MPFR is inefficient, I'm far away from =20
> > this view.
> > But for my situation (simulating a long accumulator) I prefer GMP, =20
> > cause
> > MPFR has a bigger functionality than I need and that makes it slow =20
> > for my
> > purpose.
> I don't see how bigger functionality and speed are related. Do you =20
> have actual numbers to back up your statement, or is this just an =20
> instance of the old `C++ is slow' mentality?
> > The only advantage is the closing rouned double conversion.
> > Of course later on a comparison between my implementation and MPFR =20
> > would be
> > interesting.
> I find it very hard to believe that you could do better than MPFR. =20
> It's not like the MPFR authors are some random web/VB code monkeys =20
> releasing a weekend project on Sourceforge.

I tested my computation throughout with GMP and as well with MPFR. Working
with a large accumulator (in my case a variable with precision of 4288
bits), in which perhaps only some few limbs are used, the mpfr-version is
about a factor of 4-5 slower. That has neither anything to do, that the mpfr
authors are 'some random web/VB code monkeys', nor that 'C++ is slow'. The
mpfr-library just doesn't fit to my  problem. The way some things are
realized in gmp seem to be more profitable to me (just in my case, not

Greets, Heinz

GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat:

More information about the gmp-discuss mailing list