@LanHoaHa: "Hi there,
I believe there are something wrong with some particular calculations in 
Infopath as follows:
One form includes a repeating table with 3 columes: field 1 at colume 1, 
field 2 at colume 2, field 3 at colume 3. When value in field 1 multiplies 
with value in field 2 and the result is in field 3, sometimes the results are 
not consistent in the places of decimal:
    Field 1 * Field 2      Field 3     
(1) 2.49   *  4500   =  11,205.000000000 and
(2) 2.47   *  4500   =  11,115
(3) 2.49   *  3000   =  7,470.000000000   and
(4) 2.49   *  1000   =  2490
As you see in the (1) calculation, can you please explain me why how come 
this could give a result with ".000000000" while the (2) gives no decimal? 
Hope you see my point. The same thing happens for the (3) and (4). Please 
also be noted these figures: 2.494, 3.49, 2.499, 2.99 also generate result 
with nine decimals when multiply with 4500 or 5000 or 7000 or 9000...And they 
give no decimal when multiply with 4900, ...??? 
Just to give you more background: all the three fields here are formated as:
Data type: Decimal (double)
Decimal format: Number 
                       Decimal places: Auto
                       Use a digit grouping symbol: checked
......
Please kindly have a look at this and reply to us at your earliest 
convenience.
Many thanks !
This post is a suggestion for Microsoft, and Microsoft responds to the 
suggestions with the most votes. To vote for this suggestion, click the "I 
Agree" button in the message pane. If you do not see the button, follow this 
link to open the suggestion in the Microsoft Web-based Newsreader and then 
click "I Agree" in the message pane.
<url>"
    @bojanam: "InfoPath uses XPath 1.0 which uses binary arithmetic instead of decimal 
arithmetic.  Because of this, you'll get the results listed below.
-Bojana
"Lan Hoa Ha" <email_address> wrote in message 
news:<email_address>
<quote>"
    @bojanam: "More details on this:
Floating point is the correct terminology here.
XPath uses floating point arithmetic which means that results will be 
inaccurate.
In this case, the number returned is 11205.000000000001.  The display engine 
truncates this to 11205.000000000 since NLS can only display 9 decimal 
digits.
So, yes, this is a bug, but we can't fix it.
"Bojana Marjanovic [MSFT]" <email_address> wrote in message 
news:<email_address>
<quote>"
{'source': 'USENET', 'other_information': '{"reply_count": 2, "forum_name": "microsoft.public.infopath.20140606.mbox"}', 'file': 'data/output/usenet-microsoft.public.parquet'}