<story><title>9999999999999999.0 – 9999999999999998.0</title><url>http://geocar.sdf1.org/numbers.html</url></story><parent_chain><item><author>TFortunato</author><text>How do you mean? The x86-64 instruction set &amp;#x2F; abi specifies long doubles as 80-bits, and still supports them ...</text></item><item><author>garmaine</author><text>That hasn’t been the case for over a decade.</text></item><item><author>TFortunato</author><text>So interestingly, processor makers are on the same page with you re: computations, and lots of processors can internally do computations in &amp;quot;extended precision&amp;quot;, e.g. 80-bit floats, only converting to&amp;#x2F;from 64-bit doubles at the start and end of the computation.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.m.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Extended_precision&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.m.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Extended_precision&lt;/a&gt;</text></item><item><author>erik_seaberg</author><text>There&amp;#x27;s no reason for every step of a computation to be confined to the same &lt;i&gt;very small&lt;/i&gt; message length. And the necessary error analysis should be built into the language, preferably in the same &amp;quot;advanced users only, here be dragons&amp;quot; package as the imprecise types themselves.</text></item><item><author>lenticular</author><text>Yeah, the limitations of FP are well-known to anyone who does much numerical work.&lt;p&gt;Floating point numbers are the optimal minimum message length method of representing reals with an improper Jeffery&amp;#x27;s prior distribution. A Jeffery&amp;#x27;s prior is a prior that is &lt;i&gt;invariant&lt;/i&gt; under reparameterization, which is a mandatory property for approximating the reals.&lt;p&gt;In this case, it is where Prob(log(|x|)) is proportional to a constant.&lt;p&gt;Thus, we aren&amp;#x27;t going to ever do better than floats if we are programming on physical computers that exist in this universe. There is a reason why all numerical code uses them. Best to learn their limitations if you are going to use them, otherwise use arbitrary precision.</text></item><item><author>twtw</author><text>I don&amp;#x27;t understand all the crap that IEEE 754 gets. I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don&amp;#x27;t understand the people who &amp;quot;understand&amp;quot; floating point and continue to criticize it for the 0.1 + 0.2 &amp;quot;problem.&amp;quot;&lt;p&gt;The fact is that IEEE 754 is an exceptionally good way to approximate the reals in computers with a minimum number of problems or surprises. People who don&amp;#x27;t appreciate this should try to do math in fixed point to gain some insight into how little you have to think about doing math in floating point.&lt;p&gt;This isn&amp;#x27;t to say there aren&amp;#x27;t issues with IEEE 754 - of course there are. Catastrophic cancellation and friends are not fun, and there are some criticisms to be made with how FP exceptions are usually exposed, but these are pretty small problems considering the problem is to fit the reals into 64&amp;#x2F;32&amp;#x2F;16 bits and have fast math.</text></item></parent_chain><comment><author>simonbyrne</author><text>Essentially there are two different sets of floating point instructions on x86 and x86-64: 
- the x87 instructions, which descend from the original 8087 coprocessor (and have 80-bit registers), and
- the SSE instructions, which descend from the Pentium MMX feature set, are faster, support SIMD operations, and can be fully pipelined.&lt;p&gt;The x87 instructions are basically for legacy compatibility, or if you manually use long doubles on some platforms.&lt;p&gt;The idea behind extended precision registers was good in theory, but ultimately caused too much hassle in practice.</text></comment>
<story><title>9999999999999999.0 – 9999999999999998.0</title><url>http://geocar.sdf1.org/numbers.html</url></story><parent_chain><item><author>TFortunato</author><text>How do you mean? The x86-64 instruction set &amp;#x2F; abi specifies long doubles as 80-bits, and still supports them ...</text></item><item><author>garmaine</author><text>That hasn’t been the case for over a decade.</text></item><item><author>TFortunato</author><text>So interestingly, processor makers are on the same page with you re: computations, and lots of processors can internally do computations in &amp;quot;extended precision&amp;quot;, e.g. 80-bit floats, only converting to&amp;#x2F;from 64-bit doubles at the start and end of the computation.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.m.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Extended_precision&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.m.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Extended_precision&lt;/a&gt;</text></item><item><author>erik_seaberg</author><text>There&amp;#x27;s no reason for every step of a computation to be confined to the same &lt;i&gt;very small&lt;/i&gt; message length. And the necessary error analysis should be built into the language, preferably in the same &amp;quot;advanced users only, here be dragons&amp;quot; package as the imprecise types themselves.</text></item><item><author>lenticular</author><text>Yeah, the limitations of FP are well-known to anyone who does much numerical work.&lt;p&gt;Floating point numbers are the optimal minimum message length method of representing reals with an improper Jeffery&amp;#x27;s prior distribution. A Jeffery&amp;#x27;s prior is a prior that is &lt;i&gt;invariant&lt;/i&gt; under reparameterization, which is a mandatory property for approximating the reals.&lt;p&gt;In this case, it is where Prob(log(|x|)) is proportional to a constant.&lt;p&gt;Thus, we aren&amp;#x27;t going to ever do better than floats if we are programming on physical computers that exist in this universe. There is a reason why all numerical code uses them. Best to learn their limitations if you are going to use them, otherwise use arbitrary precision.</text></item><item><author>twtw</author><text>I don&amp;#x27;t understand all the crap that IEEE 754 gets. I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don&amp;#x27;t understand the people who &amp;quot;understand&amp;quot; floating point and continue to criticize it for the 0.1 + 0.2 &amp;quot;problem.&amp;quot;&lt;p&gt;The fact is that IEEE 754 is an exceptionally good way to approximate the reals in computers with a minimum number of problems or surprises. People who don&amp;#x27;t appreciate this should try to do math in fixed point to gain some insight into how little you have to think about doing math in floating point.&lt;p&gt;This isn&amp;#x27;t to say there aren&amp;#x27;t issues with IEEE 754 - of course there are. Catastrophic cancellation and friends are not fun, and there are some criticisms to be made with how FP exceptions are usually exposed, but these are pretty small problems considering the problem is to fit the reals into 64&amp;#x2F;32&amp;#x2F;16 bits and have fast math.</text></item></parent_chain><comment><author>leiroigh</author><text>And nobody uses this terrible mis-feature in practice, everything runs via 64 bit xmm registers.&lt;p&gt;Rightly so, because programmers want their optimizing compiler to decide when to put a variable on the stack and when to elide a store&amp;#x2F;load cycle by keeping it in a register. With 80 bit precision, this makes a semantic difference and you end up in volatile hell.</text></comment>