4 ms·

I figured reading from the reddit post this is related to IEEE special way of writing two. But why IEEE has a special way of writing two?

by speeder 14y ago

DannyBee 14y ago
It's not a special way of writing two. It was a way of getting identical bit patterns for IEEE floats on all platforms. Until recently, most compilers would do host arithmetic and then convert it to target bit pattern. You would get within epsilon equal values, but not always the same bit pattern. Now all these compilers use multiprecision float libraries (either MPFR or custom-written), so the bit patterns will always come out the same. As such, there is no need for the explicit bit patterns anymore, so they just use "2.0".
- speeder 14y ago
  And why it was so important to ensure the bit pattern was the same?
  - simcop2387 14y ago
    Mostly for testing and the ability to reproduce the same issue/error/bug on many different platforms. Before it could be a little hard to debug if you compiled on one machine that had one interpretation of IEEE754 (most likely in when to round and what direction) for releases and the devs all had a machine that did it another way. This would mean that the values would be different and could throw off quite a few things for simulations and other areas with heavy floating point numbers.
    - fleitz 14y ago
      It can also wreak havok on render farms. Apparently intel and amd floating points are different enough that you can't mix and match inside the farm.
      - Dylan16807 14y ago
        Using the same compiler with the same instruction set/ordering running on each processor? That sounds astoundingly broken; can you find a reference?
        Someone 14y ago
        That same compiler need not produce the same code for each target. For example, one CPU might be so slow running instruction X that it is faster to emulate it, while it could be faster on the other. There also are floating instructions where CPUs do not compute all bits of the correct result. See http://www.zqna.net/qna/knvvzn-do-fp-operations-give-exactly-the-same-result-on-various-x86-cpus.html http://www.zqna.net/qna/knvvzn-do-fp-operations-give-exactly.... Also, not all CPUs produce the same result. In https://blogs.oracle.com/jag/entry/transcendental_meditation https://blogs.oracle.com/jag/entry/transcendental_meditation, James Gosling claims: "As far as I know, the K5 is the only x86 family CPU that did sin/cos accurately. AMD went back to being bit-for-bit compatibile with the old x87 behavior, assumably because too many applications broke"
        Dylan16807 14y ago
        What I meant is if your primary concert is identical results it should be using the same target, with no runtime changing based on instructions on one processor or another. Anyway, K5 was almost two decades ago. If you use recent processors, or even better avoid x87 instructions entirely, are you still going to have different float results?
        Someone 14y ago
        How do you check that your code never switches paths depending on CPU architecture? How do you guarantee that for the (third party) libraries you use, including your C library? Also, I think modern x86 has a "approximate 1/x" instruction that is there to be as fast as possible and, because of that, allows for differences in results. I don't know whether that is true, or whether different implementations actually exist, though.
  - fafner 14y ago
    Those constants are meant to be used in low level floating point library code. So bit patterns are critical here if you don't want these functions broken in a subtle way. Here is the patch that introduced the bug http://www.sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=99136f82027a5d6276c94a25d8392a7b571a08a3 http://www.sourceware.org/git/gitweb.cgi?p=glibc.git;a=commi...
- makomk 14y ago
  Looking at the diff they're now using the new hexadecimal format for representing IEEE floats, which didn't exist until recently but is a much cleaner way of writing bit-exact float values.
deleted 14y ago
[deleted]

I figured reading from the reddit post this is related to IEEE special way of writing two. But why IEEE has a special way of writing two?

by speeder 14y ago

I figured reading from the reddit post this is related to IEEE special way of writing two. But why IEEE has a special way of writing two?

DannyBee 14y ago

It's not a special way of writing two. It was a way of getting identical bit patterns for IEEE floats on all platforms. Until recently, most compilers would do host arithmetic and then convert it to target bit pattern. You would get within epsilon equal values, but not always the same bit pattern. Now all these compilers use multiprecision float libraries (either MPFR or custom-written), so the bit patterns will always come out the same. As such, there is no need for the explicit bit patterns anymore, so they just use "2.0".

speeder 14y ago
And why it was so important to ensure the bit pattern was the same?
- simcop2387 14y ago
  Mostly for testing and the ability to reproduce the same issue/error/bug on many different platforms. Before it could be a little hard to debug if you compiled on one machine that had one interpretation of IEEE754 (most likely in when to round and what direction) for releases and the devs all had a machine that did it another way. This would mean that the values would be different and could throw off quite a few things for simulations and other areas with heavy floating point numbers.
  - fleitz 14y ago
    It can also wreak havok on render farms. Apparently intel and amd floating points are different enough that you can't mix and match inside the farm.
    - Dylan16807 14y ago
      Using the same compiler with the same instruction set/ordering running on each processor? That sounds astoundingly broken; can you find a reference?
      - Someone 14y ago
        That same compiler need not produce the same code for each target. For example, one CPU might be so slow running instruction X that it is faster to emulate it, while it could be faster on the other. There also are floating instructions where CPUs do not compute all bits of the correct result. See http://www.zqna.net/qna/knvvzn-do-fp-operations-give-exactly-the-same-result-on-various-x86-cpus.html http://www.zqna.net/qna/knvvzn-do-fp-operations-give-exactly.... Also, not all CPUs produce the same result. In https://blogs.oracle.com/jag/entry/transcendental_meditation https://blogs.oracle.com/jag/entry/transcendental_meditation, James Gosling claims: "As far as I know, the K5 is the only x86 family CPU that did sin/cos accurately. AMD went back to being bit-for-bit compatibile with the old x87 behavior, assumably because too many applications broke"
        Dylan16807 14y ago
        What I meant is if your primary concert is identical results it should be using the same target, with no runtime changing based on instructions on one processor or another. Anyway, K5 was almost two decades ago. If you use recent processors, or even better avoid x87 instructions entirely, are you still going to have different float results?
        Someone 14y ago
        How do you check that your code never switches paths depending on CPU architecture? How do you guarantee that for the (third party) libraries you use, including your C library? Also, I think modern x86 has a "approximate 1/x" instruction that is there to be as fast as possible and, because of that, allows for differences in results. I don't know whether that is true, or whether different implementations actually exist, though.
- fafner 14y ago
  Those constants are meant to be used in low level floating point library code. So bit patterns are critical here if you don't want these functions broken in a subtle way. Here is the patch that introduced the bug http://www.sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=99136f82027a5d6276c94a25d8392a7b571a08a3 http://www.sourceware.org/git/gitweb.cgi?p=glibc.git;a=commi...
makomk 14y ago
Looking at the diff they're now using the new hexadecimal format for representing IEEE floats, which didn't exist until recently but is a much cleaner way of writing bit-exact float values.

deleted 14y ago

[deleted]