You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the FPU control word or _MM_SET_FLUSH_ZERO_MODE is toggled the algorithm doesn't work.
-- stephen.mercer
Can you go into more detail about the severity of this? If we were to use your code in our application, when would this occur? What could we do to prevent it? And when the algorithm doesn't work, does that mean your strings are junk or are they just not the shortest strings?
Quoting Arash Partow (author of http://www.codeproject.com/Articles/23198/C-String-Toolkit-StrTk-Tokenizer):
"But in short both the atod and dtoa functionalities of [the double-conversion] library have issues with double and float types when values approach denormalized but are not denormalized, there is inconsistent behavior from what is expected when the FPU control word or _MM_SET_FLUSH_ZERO_MODE is toggled - both from a performance and precision standpoint."
If you don't modify the __MM_SET_FLUSH_ZERO_MODE flag, or if you don't care about numbers with an absolute value <= 2.2250738585072009 × 10^−308 (or close to it), you should be fine.
The text was updated successfully, but these errors were encountered:
From http://code.google.com/p/double-conversion/issues/detail?id=36 :
When the FPU control word or _MM_SET_FLUSH_ZERO_MODE is toggled the algorithm doesn't work.
-- stephen.mercer
Can you go into more detail about the severity of this? If we were to use your code in our application, when would this occur? What could we do to prevent it? And when the algorithm doesn't work, does that mean your strings are junk or are they just not the shortest strings?
-- floitsch
_MM_SET_FLUSH_ZERO_MODE is used to flush denormals to 0 (see http://en.wikipedia.org/wiki/Denormal_number).
Quoting Arash Partow (author of http://www.codeproject.com/Articles/23198/C-String-Toolkit-StrTk-Tokenizer):
"But in short both the atod and dtoa functionalities of [the double-conversion] library have issues with double and float types when values approach denormalized but are not denormalized, there is inconsistent behavior from what is expected when the FPU control word or _MM_SET_FLUSH_ZERO_MODE is toggled - both from a performance and precision standpoint."
If you don't modify the __MM_SET_FLUSH_ZERO_MODE flag, or if you don't care about numbers with an absolute value <= 2.2250738585072009 × 10^−308 (or close to it), you should be fine.
The text was updated successfully, but these errors were encountered: