summaryFunction "sum" not working as expected

[acarur01]

We've noticed a discrepancy in the latest 9.1p build where the sum in the summary row shows a different value than was expected in 8.3. Take the sample. Notice that sum of "gdp" shows 167.5899999999999999999999999999999999999999....when it is supposed to show 167.59

[acarur01]

Hi, it has been more than 48hrs...could someone please respond.

[Isomorphic]

We'll take a look and update this thread today

[Isomorphic]

This sample seems to show unrounded summary values in all versions, including 8.3.

You can format the values if you want to - see the doc for ListGridField.formatGroup/GridSummary().

[acarur01]

Mm..no that sample I attached in 8.3 was showing a rounded number.

[acarur01]

I should clarify - the 8.3 version we had before we moved to 9.1 was upgrade to SmartClient_v83p_2013-08-15_PowerEdition which was showing 167.59

[acarur01]

Also, regardless of whether the latest version of 8.3 and 9.1 is showing unrounded numbers, the human eye can see that those numbers added do not equal 167.58999999999999999. Please fix it.

[Isomorphic]

We're looking into it

[Isomorphic]

Testing 8.3 as far back as November 2012, we still don't show this sample as ever doing as you claim.

To make it work, you would need to specify decimalPrecision: 2 on your ListGridField - and for that to work, you would also have to make your ListGridField type: "float".

[acarur01]

Perhaps maybe you are looking at the wrong number. My complaint is towards the sum of the first grouping. I downloaded the very latest 8.3p and it still behaves the way I would expect - to show two decimal points. I uploaded a visual just in case you are still confused.

[Isomorphic]

So what's going on here is a behavior change in an area that has no specified behavior.

In your test code, the type of the field is not declared and effectively defaults to "text". Applying summaryFunction:"sum" to a text field has no specified behavior.

In 8.3 it happened to ultimately lead to rounding through a very circuitous process; the correct, supported way to get this behavior is to actually declare the field as type:"float" and set decimalPrecision.

Also, FYI, adding floating point numbers in any common programming language (JavaScript, Java, C..) leads to these kind of results. Here is one of many brief explanations, or if you want the incredibly long story, try this.