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:
var test = (Field_1.rawValue/Field_2.rawValue)*100;
app.alert(""+test);
Can one tell me what I'm doing wrong? Thanks.
Solved! Go to Solution.
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
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Indeed looks similar. What is even more funny is that problem concerns only number 7 (lucky number for Adobe I guess).
Views
Replies
Total Likes
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
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
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies