SUMFIELD starts producing wrong results with large tables

I have a FormQueryPlugin generated table that has just crossed about 230 items/rows. At the bottom of the table I am using SUMFIELD to total a value. I note that the value is now being incorrectly produced. The number is "close" to being accurate, and I was only drawn to it because my up to then currency (two decimal place) figures where being summed to sum number with many decimal places eg. 8853.07999999999 instead of 8853.08. There is no other calc going on, all the figures are strictly 2 decimal places.

I think I recall coming across a note to this effect this "years ago", but can't find it now. I wonder if someone else can enlighten me before I spend too long trolling through the (to me) obtuse code. is this just a strange Perl artefact?...

-- ScottClaridge - 10 Jan 2010

Yes.

-- CrawfordCurrie - 09 Mar 2010

um, more like not quite. Its not a Perl artifact, rather an artifact of using a datatype (floating point) which is inappropriate to your result needs.

sven@quad7:~$ more floats.c 
#include <stdio.h>

int main() {
   float test;

   test = 8853.08;
   printf("tester == %f \n", test);

   return 1;
}
sven@quad7:~$ ./a.out 
tester == 8853.080078

in essence, 8853.08 is a number that isn't able to be stored exactly by a float - producing this kind of quantization effect This is why floats are not typically used for currency calculations :/.

you will have more joy by doing your calculations in cents, and then rendering the output as a string into which you add a decimal point.

There is allot more accurate information at http://wikipedia.org/wiki/Floating_point - its been many years since i discussed this (or done formal error analysis), so I've forgotten the words, and the theoretical background.

-- SvenDowideit - 10 Mar 2010