Strange behavior of mpf_inp_str

Ronald Bruck rbruck at gmail.com
Thu Feb 18 07:49:47 CET 2010


GMP 5.0.1 compiled OK, passing "make check", on my system (an i7 running SuSE 9.1).  But mpf_inp_str seems to be behaving strangely.  I've finally isolated it to a simple example, and I'd like to know how this behaves on other's systems.

Program file "test.c":
==================
#include <stdio.h>
#include <gmp.h>

int main ()
{
  int c, i, b;
  mpf_t t;

mpf_init2 (t, 128);

while ((c = fgetc(stdin)) != EOF) {
  ungetc (c, stdin);
  scanf ("%d", &i);
  b = mpf_inp_str (t, stdin, 10);
  c = fgetc (stdin);  /* to skip the newline*/
  gmp_printf ("%d %d %Fe\n", i, b, t);
}
====================

I compiled it with

icc -o test test.c -lgmp

and executed it via

./test < err,

where err contains two lines:

File err
========================
1 3.2719832
7 4.2814896e+14
========================

and the output is

1 10 3.271983e+00
1 0 3.271983e+00

The second mpf_inp_str read 0 bytes, and didn't work.

In fact, the problem seems to be the + sign in the exponent.  It consistently works with expressions like e32 or
e-32, but not e+32.  It then reads 0 bytes.

Is this some freakish behavior of my system, or a bug introduced in version 5, or has it always behaved like this? (I can't believe that, because I've been running my code since 2001, and it consistently agreed with the double-precision standard program csdp.)

I suppose I should test it with gcc.  Now that WOULD be freaky if the code suddenly works...

I started using mpf_inp_str before you introduced the gmp_printf and its partners.  But I still like it because it can read hexadecimal to full precision.  Precision of decimal numbers is somewhat nebulous.  What I mean by that is, when I do a calculation to say 512 bits and save the results as decimals, when I later re-read the file I have no idea what precision I used.  I have to scan the whole file to find the maximum decimal precision, translate that back to bits, and use the new value in subsequent calculations.  Writing as hexadecimal to full precision is much better.  

Wonderful job you guys are doing!  Is anybody working on trying to get the package to run on one of the graphics chips?  Problem is, they're optimized for FP, and GMP uses integer multiplies.  Perhaps Bailey's multiprecision package would be easier to adapt.  

-- Ron Bruck





More information about the gmp-bugs mailing list