Expand my Community achievements bar.

SOLVED

Adobe Forms calculation bug?

Avatar

Level 2

Just discovered, by accident, that simple calculations in PDF forms can produce unexpected results.

I'm dividing 7 by 100 and multiplying the result by 100. What do you think one should get? 7? Not really.

Adobe form thinks it is: 7.000000000000001

To reproduce the issue:

  • create a simple form with two decimal fields (field1 and field2);
  • add script for exit event from the second field:

          var test = (Field_1.rawValue/Field_2.rawValue)*100;

          app.alert(""+test);

Can one tell me what I'm doing wrong? Thanks.

issue.png

1 Accepted Solution

Avatar

Correct answer by
Level 10

Hi,

You can see the same thing with 0.1 + 0.2 which gives 0.30000000000000004.  This is because 0.1 can not be represented precisely in a 64 bit floating point number, just like 0.07 can't, but 0.03 and 0.09 can.

You might need to add some rounding;

((7/100)*100).toFixed(2)

gives

7.00

There's lots of links about this, but they get pretty heavy, How numbers are encoded in JavaScript

Regards

Bruce

View solution in original post

9 Replies

Avatar

Level 2

I have something similar to this, I have a numeric field1 = .59 + numeric field2 = .31 should = .90, if I display result in console I get 0.8999999999999999, if I display result in numeric field I get .90.

Avatar

Level 2

Indeed looks similar. What is even more funny is that problem concerns only number 7 (lucky number for Adobe I guess).

Avatar

Level 10

Hi,

I think this is how JavaScript works, Chrome gives the same result.  There is no decimal or integer type, all numbers are floating point so at some point become imprecise.  Try pasting the number 72057594037927937  into a numeric field you will get 72057594037927936.

The number 72057594037927937 is (2 ^ 56) + 1 ... one more than the biggest integer JavaScript can handle.

Bruce

Avatar

Level 2

Not true, why (6/100)*100 is 6, same for all other numbers but not 7. See the test file here: http://share-it.info/test/bug_adobe.zip

Avatar

Level 10

Bruce is right, JavaScript works with 64-Bit (double precision) floating point numbers only after IEEE 754, which allows a 53-Bit integer a range from -9.007.199.254.740.992 to 9.007.199.254.740.992.

During calculation JavaScript converts floating point numbers into 32 Bit binary numbers and back, which can cause rounding issues in decimal places as this will be rounded up to the next real number within the available range..

This book describes it very good.

Effective JavaScript: 68 Specific Ways to Harness the Power of JavaScript Effective Software Develop...

Avatar

Level 2

Have you tried my file? 7/100 = 0.07 * 100 = 7 (we are not talking about divisions that give infinite decimals like 2/3)

No magic here. Why would (7/100)*100 = 7,0000000000001 while in the same file (3/100)*100 = 3, (5/100)*100 = 5, (9/100)*100 = 9 and so on.

Avatar

Correct answer by
Level 10

Hi,

You can see the same thing with 0.1 + 0.2 which gives 0.30000000000000004.  This is because 0.1 can not be represented precisely in a 64 bit floating point number, just like 0.07 can't, but 0.03 and 0.09 can.

You might need to add some rounding;

((7/100)*100).toFixed(2)

gives

7.00

There's lots of links about this, but they get pretty heavy, How numbers are encoded in JavaScript

Regards

Bruce

Avatar

Level 2

Thanks Bruce you might be right - does that mean 0.07 would be the only case of number that cannot be presented in 64 bit notation?

Story gets now even more weird, demo file giving "wrong 7.00000000001" result at home, does now seem to give correct result in the office.

However I can still reproduce the same bug in Lifecycle Designer. Can this be Adobe Reader or OS version related?

Here are some other articles concerning the floating point issue:

http://bytes.com/topic/javascript/answers/714271-strange-behaviour-multiplying-decimals-ie

Dart calculation error on 0.07 * 100 · Issue #23315 · dart-lang/sdk · GitHub

Avatar

Level 10

Hi,  I would not have expected the OS or Reader version to make a difference, nor any locale differences.  What versions of OS/Reader are you using?  Bruce