mpf: which bug should we correct? (doc or code)

Torbjörn Granlund tg at
Mon Jun 2 11:31:13 UTC 2014

  > Instead of re-implementing mpfr, an easy fix would be to simply drop mpf
  "simply" breaking backward compatibility is easy on our side, but it may
  be not on users side...
  Of course I agree, there is no need to (re-)implement correct rounding.
  The best fix probably is to relax the claim in the documentation...
I'm tempted to do just that, but we might want to improve mpf instead.
It's not clear at all what is best here.

I think mpf is still used a lot.

  > from gmp and refer people to mpfr...
  We usually do. I mean, people asking for floating-point operations on GMP
  lists usually get a "look at MPFR" answer.
  Also the manual of GMP refers to MPFR for "well-defined precision and
  accurate rounding".
And on the web page we say
 "New projects should strongly consider using the much more complete GMP
  extension library mpfr instead of mpf."

(The use of the phrase "GMP extension library" might sound like we're
somehow claiming credit for MPFR.  I used that phrasing as a sort of

Please encrypt, key id 0xC8601622

More information about the gmp-devel mailing list