Just for fun and because it was really easy, I&#39;ve written a short program to generate [Grafting numbers](http://math.wikia.com/wiki/Grafting_number), but because of floating point precision issues it&#39;s not finding some of the larger examples.

    def isGrafting(a):
      for i in xrange(1, int(ceil(log10(a))) + 2):
        if a == floor((sqrt(a) * 10**(i-1)) % 10**int(ceil(log10(a)))):
          return 1
    
    a = 0
    while(1):
      if (isGrafting(a)):
        print &quot;%d %.15f&quot; % (a, sqrt(a))
      a += 1

This code misses at least one known Grafting number. `9999999998 =&gt; 99999.99998999999999949999999994999999999374999999912...`  It seems to drop extra precision after multiplying by `10**5`.

    &gt;&gt;&gt; a = 9999999998
    &gt;&gt;&gt; sqrt(a)
    99999.99999
    &gt;&gt;&gt; a == floor((sqrt(a) * 10**(5)) % 10**int(ceil(log10(a))))
    False
    &gt;&gt;&gt; floor((sqrt(a) * 10**(5)) % 10**int(ceil(log10(a))))
    9999999999.0
    &gt;&gt;&gt; print &quot;%.15f&quot; % sqrt(a)
    99999.999989999996615
    &gt;&gt;&gt; print &quot;%.15f&quot; % (sqrt(a) * 10**5)
    9999999999.000000000000000

So I wrote a short C++ program to see if it was my CPU truncating the floating point number or python somehow.

    #include &lt;cstdio&gt;
    #include &lt;cmath&gt;
    #include &lt;stdint.h&gt;
    
    int main()
    {
      uint64_t a = 9999999998;
      printf(&quot;%ld %.15f %.15f %.15f %.15f\n&quot;, a, sqrt((double)a), sqrt((double)a)*1e4, sqrt((double)a)*1e5, sqrt((double)a)*1e6);
      a = 999999999998;
      printf(&quot;%ld %.15f %.15f %.15f %.15f\n&quot;, a, sqrt((double)a), sqrt((double)a)*1e5, sqrt((double)a)*1e6, sqrt((double)a)*1e7);
      a = 99999999999998;
      printf(&quot;%ld %.15f %.15f %.15f %.15f\n&quot;, a, sqrt((double)a), sqrt((double)a)*1e6, sqrt((double)a)*1e7, sqrt((double)a)*1e8);
      return 0;
    }
    
Which outputs:

    9999999998 99999.999989999996615 999999999.899999976158142 9999999999.000000000000000 99999999990.000000000000000
    999999999998 999999.999998999992386 99999999999.899993896484375 999999999999.000000000000000 9999999999990.000000000000000
    99999999999998 9999999.999999899417162 9999999999999.900390625000000 99999999999999.000000000000000 999999999999990.000000000000000

So it looks like I&#39;m running up hard against the limits of floating point precision and the CPU is chopping off the remaining bits because it thinks that the remaining difference is floating point error.  Is there a way to work around this under Python?  Or do I need to move to C and use GMP or something?

Is floating point arbitrary precision available?

Yesterday during debugging something strange happened to me and I can&#39;t really explain it:

[![Decimal calculation][1]][1]


[![Decimal calculations with brackets][2]][2]


  [1]: http://i.stack.imgur.com/MEcIg.jpg
  [2]: http://i.stack.imgur.com/D3D9R.jpg

So maybe I am not seeing the obvious here or I misunderstood something about decimals in .NET but shouldn&#39;t the results be the same?


Inaccuracy of decimal in .NET

Is there a bignum built into JavaScript or browsers?

The alternate is loading an external library like

    &lt;script type=&quot;text/javascript&quot; src=&quot;the_bignum_library.js&quot;&gt;&lt;/script&gt;

but that seems slow and may trigger a security warning.

I&#39;ve considered basing my own off of http://github.com/silentmatt/javascript-biginteger or http://www.mainebrook.com/john/fun/euler.html. Alternately, is the solution to call into a  Java bignum library such as apfloat?




What is the standard solution in JavaScript for handling big numbers (BigNum)?

The following code is obviously wrong.  What&#39;s the problem?

    i &lt;- 0.1
    i &lt;- i + 0.05
    i
    ## [1] 0.15
    if(i==0.15) cat(&quot;i equals 0.15&quot;) else cat(&quot;i does not equal 0.15&quot;)
    ## i does not equal 0.15

Why are these numbers not equal?

Consider the following code:
&lt;!-- language: lang-js --&gt;

    0.1 + 0.2 == 0.3  -&gt;  false

&lt;!-- language: lang-js --&gt;

    0.1 + 0.2         -&gt;  0.30000000000000004

Why do these inaccuracies happen?


Is floating point math broken?

According to [this java.sun page][1] `==` is the equality comparison operator for floating point numbers in Java.

However, when I type this code:

    if(sectionID == currentSectionID)

into my editor and run static analysis, I get: &quot;JAVA0078 Floating point values compared with ==&quot;

What is wrong with using `==` to compare floating point values?  What is the correct way to do it?&amp;nbsp;


  [1]: http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html

What&#39;s wrong with using == to compare floats in Java?

I know that most decimals don&#39;t have an exact floating point representation (https://stackoverflow.com/questions/588004).

But I don&#39;t see why `4*0.1` is printed nicely as `0.4`, but `3*0.1` isn&#39;t, when
both values actually have ugly decimal representations:

    &gt;&gt;&gt; 3*0.1
    0.30000000000000004
    &gt;&gt;&gt; 4*0.1
    0.4
    &gt;&gt;&gt; from decimal import Decimal
    &gt;&gt;&gt; Decimal(3*0.1)
    Decimal(&#39;0.3000000000000000444089209850062616169452667236328125&#39;)
    &gt;&gt;&gt; Decimal(4*0.1)
    Decimal(&#39;0.40000000000000002220446049250313080847263336181640625&#39;)

Why does the floating-point value of 4*0.1 look nice in Python 3 but 3*0.1 doesn&#39;t?

Is it possible to get division by 0 (or infinity) in the following example? 

&lt;!-- language: java --&gt;

    public double calculation(double a, double b)
    {
         if (a == b)
         {
             return 0;
         }
         else
         {
             return 2 / (a - b);
         }
    }

In normal cases it will not, of course. But what if `a` and `b` are very close, can `(a-b)` result in being `0` due to precision of the calculation?

Note that this question is for Java, but I think it will apply to most programming languages.


Is it possible to get 0 by subtracting two unequal floating point numbers?

I have a large amount of numeric values `y` in javascript.  I want to group them by rounding them down to the nearest multiple of `x` and convert the result to a string. 

How do I get around the annoying floating point precision?  

For example:

    0.2 + 0.4 = 0.6000000000000001

Two things I have tried:

    &gt;&gt;&gt; y = 1.23456789 
    &gt;&gt;&gt; x = 0.2 
    &gt;&gt;&gt; parseInt(Math.round(Math.floor(y/x))) * x; 
    1.2000000000000002

and:

    &gt;&gt;&gt; y = 1.23456789 
    &gt;&gt;&gt; x = 0.2 
    &gt;&gt;&gt; y - (y % x)
    1.2000000000000002

Dealing with float precision in Javascript

I am trying to truncate decimal numbers to decimal places. Something like this:
 
    5.467   -&gt; 5.46  
    985.943 -&gt; 985.94

`toFixed(2)` does just  about the right thing but it rounds off the value. I don&#39;t need the value rounded off. Hope this is possible in javascript.

Truncate (not round off) decimal numbers in javascript

Is there a way to programmatically get the double that is closest to 1.0, but isn&#39;t actually 1.0?

One hacky way to do this would be to memcpy the double to a same-sized integer, and then subtract one.  The way IEEE754 floating-point formats work, this would end up decreasing the exponent by one while changing the fractional part from all zeros (1.000000000000) to all ones (1.111111111111).  However there exist machines where integers are stored little-endian while floating-point is stored big-endian, so that won&#39;t always work.

What&#39;s the closest double to 1.0, that isn&#39;t 1.0?

    $a = &#39;35&#39;;
    $b = &#39;-34.99&#39;;
    echo ($a + $b);

Results in 0.009999999999998

What is up with that? I wondered why my program kept reporting odd results.

Why doesn&#39;t PHP return the expected 0.01?

PHP - Floating Number Precision

I know `UIKit` uses `CGFloat` because of the resolution independent coordinate system.

But every time I want to check if for example `frame.origin.x` is `0` it makes me feel sick:

    if (theView.frame.origin.x == 0) {
        // do important operation
    }

Isn&#39;t `CGFloat` vulnerable to false positives when comparing with `==`, `&lt;=`, `&gt;=`, `&lt;`, `&gt;`?
It is a floating point and they have unprecision problems: `0.0000000000041` for example.

Is `Objective-C` handling this internally when comparing or can it happen that a `origin.x` which reads as zero does not compare to `0` as true?

How dangerous is it to compare floating point values?

See this code:

&lt;!-- begin snippet: js hide: false console: true babel: false --&gt;

&lt;!-- language: lang-js --&gt;

    var jsonString = &#39;{&quot;id&quot;:714341252076979033,&quot;type&quot;:&quot;FUZZY&quot;}&#39;;
    var jsonParsed = JSON.parse(jsonString);
    console.log(jsonString, jsonParsed);

&lt;!-- end snippet --&gt;

When I see my console in Firefox 3.5, the value of `jsonParsed` is the number rounded:

    Object id=714341252076979100 type=FUZZY

Tried different values, the same outcome (number rounded).

I also don&#39;t get its rounding rules. 714341252076979136 is rounded to 714341252076979200, whereas 714341252076979135 is rounded to 714341252076979100.

Why is this happening?

Large numbers erroneously rounded in JavaScript

    assert(0.1 + 0.2 != 0.3); // shall be true

is my favorite check that a language uses native floating point arithmetic.

## C++ ##

    #include &lt;cstdio&gt;
     
    int main()
    {
       printf(&quot;%d\n&quot;, (0.1 + 0.2 != 0.3));
       return 0;
    }

Output:

    1
http://ideone.com/ErBMd

## Python ##

    print(0.1 + 0.2 != 0.3)

Output:

    True

http://ideone.com/TuKsd

## Other examples ##

 - Java: http://ideone.com/EPO6X
 - C#: http://ideone.com/s14tV

Why is this not true for D? As understand D uses native floating point numbers. Is this a bug? Do they use some specific number representation? Something else? Pretty confusing.

## D ##

    import std.stdio;
     
    void main()
    {
       writeln(0.1 + 0.2 != 0.3);
    }

Output:

    false

http://ideone.com/mX6zF

---
## UPDATE ##
Thanks to [LukeH][1]. This is an effect of Floating Point Constant Folding described [there][2]. 

Code:

    import std.stdio;
     
    void main()
    {
       writeln(0.1 + 0.2 != 0.3); // constant folding is done in real precision
     
       auto a = 0.1;
       auto b = 0.2;
       writeln(a + b != 0.3);     // standard calculation in double precision
    }

Output:

    false
    true

http://ideone.com/z6ZLk


  [1]: https://stackoverflow.com/users/55847/lukeh
  [2]: http://www.d-programming-language.org/float.html





Why 0.1 + 0.2 == 0.3 in D?

My question is **not** about floating precision. It is about why `Equals()` is different from `==`.

I understand why `.1f + .2f == .3f` is `false` (while `.1m + .2m == .3m` is `true`).  
I get that `==` is reference and `.Equals()` is value comparison. (_Edit_: I know there is more to this.)

But why is `(.1f + .2f).Equals(.3f)` `true`, while `(.1d+.2d).Equals(.3d)` is still `false`?

     .1f + .2f == .3f;              // false
    (.1f + .2f).Equals(.3f);        // true
    (.1d + .2d).Equals(.3d);        // false

(.1f+.2f==.3f) != (.1f+.2f).Equals(.3f) Why?

I encountered negative zero in output from python; it&#39;s created for example as follows:

    k = 0.0
    print(-k)

The output will be `-0.0`.

However, when I compare the `-k` to 0.0 for equality, it yields True. Is there any difference between `0.0` and `-0.0` (I don&#39;t care that they presumably have different internal representation; I only care about their behavior in a program.) Is there any hidden traps I should be aware of?

All Floating Accuracy Solutions on Gang of Coders

Total of 17 Floating Accuracy Solutions