1

I have two machines, one is a MIPSPro machine running IRIX and the other one is an x86_64 machine running RHEL 6.7. In both of these machines I am reading a binary stream of data and converting each 8 bytes to a doubles. I.e both doubles contain the same bytes. I should mention that the values are being printed as soon as they read, i.e they don't have any operations placed on them. However, when I try to print it out in decimal notation, there are slight differences in the least significant bit. Ie in the MIPSPro machine my list of doubles is

0.171600586
23.04003904
1680618.1772226
...

And on x86_64 my list of doubles is

0.171600585999999
23.0400390399999
1680618.17722259
...

Both machines should have use IEEE doubles.

I have two questions. Why is there is a disagreement between the two values? That is, shouldn't a set of 64 bits map to exactly one value without any ambiguity? Why is there a difference in the way they are interpreting these values?

Iliketoproveit
  • 445
  • 6
  • 15
  • 1
    Can you print them as hex floats? – Kerrek SB Mar 26 '18 at 17:54
  • 1
    You cannot assume fp results to be 100% identical between architectures. Also; what are your compiler options (and what compiler)? You are not using `-ffast-math` or equivalent - right? – Jesper Juhl Mar 26 '18 at 17:55
  • 1
    @JesperJuhl Why not? They follow the same standard. What is the reason that the last significant digit is interpreted differently across architectures? – Iliketoproveit Mar 26 '18 at 17:57
  • @Iliketoproveit some parts of the standard is "implementation defined" so it may differ between implementations (even on the same architecture). – Jesper Juhl Mar 26 '18 at 17:58
  • @KerrekSB I'm feeding this output to some numerical analysis software so I need them to be in decimal format – Iliketoproveit Mar 26 '18 at 17:58
  • 1
    The machines are capable of supporting the IEEE754 but it doesn't mean they do out of the box. x86 programs for example, but not x86_64 ones, use the FPU that has 80-bit precision by default. Try configuring the machine for a full IEEE754 compatibility. – Margaret Bloom Mar 26 '18 at 18:01
  • @JesperJuhl I'm more interested in understanding why there even is a difference to begin with. Why is there even a discrepancy? – Iliketoproveit Mar 26 '18 at 18:02
  • @MargaretBloom So are you saying that that the x86_64 machine is interpreting the numbers with "less" precision that the MIPS machine? – Iliketoproveit Mar 26 '18 at 18:03
  • @Iliketoproveit: That was just to debug the issue. Maybe the values are actually the same but the different libraries round differently for the purpose of printing decimal strings. I wanted to separate the rounding concerns from whether the numbers are the same. – Kerrek SB Mar 26 '18 at 18:04
  • @KerrekSB I'm pretty sure that the code being used to print out these doubles is the regular `cout << double << endl` code. – Iliketoproveit Mar 26 '18 at 18:05
  • 1
    No, I'm saying that implementations matter, settings matter. Rounding, precision, etc. Try to take a look and see if everything is the same. – Margaret Bloom Mar 26 '18 at 18:06
  • @MargaretBloom I guess the root of the issue is the why. Why is there even a difference. Are they not supposed to be same number? – Iliketoproveit Mar 26 '18 at 18:12
  • Some relevant links; [Is floating point math broken?](https://stackoverflow.com/questions/588004/is-floating-point-math-broken). [What Every Computer Scientist Should Know About Floating-Point Arithmetic](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html). – Jesper Juhl Mar 26 '18 at 18:13
  • 3
    The first two numbers are likely decimal periodics and the number of 9s would extend infinitely. There is no way to "correctly" print such numbers. Converting floating point numbers to decimal notation (the algorithm for %f in printf, or the conversion in cout << double) is implemented by the system's libc, and SGI and Linux have distinct implementations. This paper shows that different systems print floating point numbers differently: https://www.cs.indiana.edu/~dyb/pubs/FP-Printing-PLDI96.pdf (table on page 8). SGI systems performed particularly bad there. – FBergo Mar 26 '18 at 18:17
  • What are the outputs if you use [std::setprecision](http://en.cppreference.com/w/cpp/io/manip/setprecision) with, say, 100? – Bob__ Mar 26 '18 at 20:57

0 Answers0