3 ms·

I remember that in university we had a test on a toy 16-bit floating point ALU. We had to walk through each of the steps in the ALU for the usual operations, s

I remember that in university we had a test on a toy 16-bit floating point ALU. We had to walk through each of the steps in the ALU for the usual operations, showing the bit patterns at each step and keeping track of precision loss, etc. Because we had to track state and some aspects of the test were randomized, there were a few cases where identical operations on identical inputs resulted in different outputs due to the residual state. During the next lecture, someone sticks their hand up and says, "this FPU thing is so nondeterministic, who in their right mind would use floating point for 99% of the kinds of work that we use computers for?" The professor says, "you should think real hard about that the next time you decide to use a floating point type in your program."

brucedawson 10y ago
> identical operations on identical inputs resulted > in different outputs due to the residual state. What? What residual state? Floating-point math is tricky, but on a particular machine/compiler/compile-options set you should expect that identical operations on identical inputs should give identical results. What is this "residual state" you mention? If you have an FPU that lets you change precision or rounding modes then you can get different results from the same operations - is that what you're talking about? I get frustrated when people think that floating-point just randomly changes bits for no reason. It doesn't. It randomly changes bits for specific reasons, which can be understood.
- effie 10y ago
  trelliscoded probably meant bits in scratchpad, which are not accessible to the programmer. I read somewhere that those hidden bits may not be saved and regenerated properly as part of cpu resuming execution of the program (task switching). I do not know if that can happen, but even if not, achieving consistency on subsequent runs is quite difficult - apparently one has to make sure the program and all libraries it uses were compiled with special compiler flags that prevent data alignment influencing results of FPU operations. https://software.intel.com/articles/consistency-of-floating-point-results-using-the-intel-compiler/ https://software.intel.com/articles/consistency-of-floating-...

brucedawson 10y ago

> identical operations on identical inputs resulted > in different outputs due to the residual state. What? What residual state? Floating-point math is tricky, but on a particular machine/compiler/compile-options set you should expect that identical operations on identical inputs should give identical results. What is this "residual state" you mention? If you have an FPU that lets you change precision or rounding modes then you can get different results from the same operations - is that what you're talking about? I get frustrated when people think that floating-point just randomly changes bits for no reason. It doesn't. It randomly changes bits for specific reasons, which can be understood.

effie 10y ago
trelliscoded probably meant bits in scratchpad, which are not accessible to the programmer. I read somewhere that those hidden bits may not be saved and regenerated properly as part of cpu resuming execution of the program (task switching). I do not know if that can happen, but even if not, achieving consistency on subsequent runs is quite difficult - apparently one has to make sure the program and all libraries it uses were compiled with special compiler flags that prevent data alignment influencing results of FPU operations. https://software.intel.com/articles/consistency-of-floating-point-results-using-the-intel-compiler/ https://software.intel.com/articles/consistency-of-floating-...