This question about Using an extension: Answered
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