Quirk with Arithmetic MUL function

[Former Member]

All,

In my source file I've got 2 fields (sf1, sf2) declared as type xsd:string. My requirement is to multiply those two fields and map the value to my destination field (df1) which is also of type xsd:string.

What I've noticed is if I have, for instance, sf1=3427.00 and sf2=97.0 then df1 is equal 332419.000 (we also send the result through a FormatNumber routine to get the 3 decimal places). In this scenario we see no issue.

The problem appears when we use larger numbers. An example we've seen is if sf1=41041.00 and sf2=817.0. The answer SHOULD be 33530497.000. What it actually does is calculate the value as 3.3530496E7. When that gets mapped to df1 it ends up getting set to 33530496.000 which is off by 1. We have other examples where the value is off by a little more than 1.

My question are:

1) Can anyone explain to me why Java/XI calculates this way (if it's not a bug) and,

2) does anyone have an idea as to how I would resolve this issue?

We are on SP15.

Thanks!

[Shabarish_Nair · Accepted solution]

<i>Function Category: Arithmetic

You can only enter numerical values for this category (this includes values with digits after the decimal point). If the value cannot be interpreted as a digit, then the system triggers a Java exception. Otherwise, all calculations are executed with the precision of the Java data type float. The format of the result value depends on the result:

&#9679; If the result is a value with digits after the decimal point, these remain unchanged.

&#9679; Exception: If a zero follows the decimal point, then this is cut off. This means that the result of the calculation 4.2 – 0.2 is 4 and not 4.0.

Also note that Java values of type float are converted to the second system before the calculation. The result is calculated there and then this result is converted back to decimal format. The conversion may result in positions after the decimal point that are periodically repeated and then automatically cut off. In the decimal system, this can result in inaccurate results (example: 2.11 + 22.11 = 24.220001). If the number of positions after the decimal point is to be restricted to two, for example, in the case of values for a currency, you can format the values after the calculation by using the standard function FormatNum.</i>

an extract from - http://help.sap.com/saphelp_nw04/helpdata/en/43/c4cdfc334824478090739c04c4a249/content.htm

[Former Member · Accepted solution]

Shabarish,

<p>Thanks for the reply. I'm not sure how that helps me though. In the example I have that is incorrect I'm only mapping numerical values to the MUL function (41041.00 and 817.0). Based on the comment:</p>

<p><i>Exception: If a zero follows the decimal point, then this is cut off. This means that the result of the calculation 4.2 – 0.2 is 4 and not 4.0.</i></p>

<p>That tells me that XI will mulitply 41041 by 817 (cutting off the zeroes). Somehow the result of that is off by 1 (should be 33530496 not 33530497).</p>

Thanks!

[Former Member · Accepted solution]

Jones,

It is a known problem in XI. To overcome this you have to switch to BigDecimal instead of float. You should go to ExchangeProfile edit page, look for property

com.sap.aii.mappingtool.flib3.bigdecimalarithmetic under the IntegrationBuilder node, and set it to true.

Check this SAP notes for the same:

Note 958486 - Arithmetic or Statistic function returns wrong result

---Satish

[stefan_grube · Accepted solution]

This requires SP18.

In SP15 you have to write a UDF for mutliplying with BigDecimal instead of float.

see this blog:

/people/thorsten.nordholmsbirk/blog/2006/04/03/never-ever-use-xis-built-in-arithmetic-functions

Regards

Stefan

[Former Member · Accepted solution]

Its my fault. I have not seen the SP level.

Jones you can write the UDF as mentioned in the blog. Then it will take care of your issue. Thanks for correcting me Stefan.

---Satish