3 ms·
The(?) posit website has a pdf[1] which goes into more details under "3.3 Posit format encoding". It also mentions a "quire" (and the footnote for the quire val
by zeotroph 4y ago
The(?) posit website has a pdf[1] which goes into more details under "3.3 Posit format encoding". It also mentions a "quire" (and the footnote for the quire value is self referential?) , can anyone explain that concept?
1: https://posithub.org/docs/posit_standard-2.pdf https://posithub.org/docs/posit_standard-2.pdf
- SanjayMehta 4y agoAs I understood it, it's a large internal register to prevent fractional errors from accumulating.
- josefx 4y agoWasn't that a gigantic issue with x87 floating point implementation? It would internally use 80 bit registers and the result of any computation was completely at the mercy of how the compiler used those 80 bit registers as every move to system memory would drop precision back to the 32 bit or 64 bit specified by the program.
- SanjayMehta 4y agoI don't really know anything about that, but it appears here that all this is done in hardware without any compilers involved.
- josefx 4y agoThe footnote for point 4.3 in the linked document above explicitly calls out optimization modes and possible non compliance. Yeah, its the x87 80 bit registers all over again.
- gliptic 4y agoExcept the compilers will not be dumb enough to use it implicitly when you don't ask for it, just like they don't automatically use FMA now (except maybe with -ffast-math).
- adgjlsfhk1 4y agoNope. C/C++ think it's OK to use fma when you didn't ask for it with default compiler settings. Also, with default settings, GCC is willing to replace single precision math with double precision math if it feels like it.
- jcranmer 4y ago> Nope. C/C++ think it's OK to use fma when you didn't ask for it with default compiler settings. No, it doesn't. You have to request #pragma STDC FP_CONTRACT ON explicitly, or use -ffp-contract flag-equivalent (implied by -ffast-math or -Ofast) on most compilers. icc is the only major compiler that actually defaults to fast-math flags. > Also, with default settings, GCC is willing to replace single precision math with double precision math if it feels like it. I'm less familiar with gcc than I am with LLVM, but I strongly doubt that this is the case. There is a provision in C/C++ for FLT_EVAL_METHOD, which indicates what the internal precision of arithmetic expressions (which excludes assignments and casts) is, and this is set to 2 on 32-bit x86, because x87 internally operates on all numbers as long double precision, only explicitly rounding to float/double when you tell it to in an extension. But on 64-bit x86, FLT_EVAL_METHOD is 0 (everybody executes according to their own type), because SSE can operate on single- or double-precision numbers directly.
- gliptic 4y agoI'm not aware of any time GCC does that except due to C++'s promotion rules (e.g. float + double -> double), which is a problem with C++, not the compiler. I write deterministic software using floating point in C++.
- adgjlsfhk1 4y agoSee https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35488/ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35488/ https://github.com/numpy/numpy/issues/15237 https://github.com/numpy/numpy/issues/15237. I slightly misremembered what was happening. It's that on 32 bit systems, it wil replace 64 bit math with 80 bit math and double rounding which can produce non IEEE compliant results.