GNOME Bugzilla – Bug 80798
numbers rounding problem
Last modified: 2009-08-15 18:40:50 UTC
When using xsltproc to convert an XML file with numeric values (bank account), the numbers loose accuracy (413.80 becomes 413.80000000000291) I don't know if this is a libc-related problem however... Version info: Using libxml 20419, libxslt 10016 and libexslt 707 xsltproc was compiled against libxml 20419, libxslt 10016 and libexslt 707 libxslt 10016 was compiled against libxml 20419 libexslt 707 was compiled against libxml 20419
Created attachment 8177 [details] set of files showing the problem
Hum, I was a bit lost in the example, si I ran the processor in verbose mode and was able to reproduce the problem (linux Red Hat 7.2 on a Duron processor). That part from the log exhibit the problem: xsltValueOf: select translate ( format-number($Amount,'###,###,###,###,##0.00############') , ',' , ' ' ) Lookup variable Amount found variable Amount xsltValueOf: result 39 413.80000000000291 Looking at the data it seems the value is 39413.80 Putting a breakpoint in xsltFormatNumberFunction() and waiting for the given value to appear I got: (gdb) 451 numberObj = valuePop(ctxt); (gdb) 452 break; (gdb) p *numberObj $4 = {type = XPATH_NUMBER, nodesetval = 0x0, boolval = 0, floatval = 39413.800000000003, stringval = 0x0, user = 0x0, index = 0, user2 = 0x0, index2 = 0} (gdb) which already indicates a deviation occured before at xmlXPathStringEvalNumber(). I have tried multiple ways to get rid of the approximation error without success. (gdb) 7113 } 6: fraction = 80 5: ret = 39413 (gdb) 7114 fraction /= my_pow10[frac]; 6: fraction = 80 5: ret = 39413 (gdb) 7115 ret = ret + fraction; 6: fraction = 0.80000000000000004 5: ret = 39413 (gdb) print my_pow10[frac]; Invalid character ';' in expression. (gdb) print my_pow10[frac] $1 = 100 (gdb) n 7116 while ((*cur >= '0') && (*cur <= '9')) 6: fraction = -nan(0x8000000000000) 5: ret = 39413.800000000003 (gdb) this is very frustrating !!!! I don't know how to cope with this at the moment. Daniel
Okay I posted on the list about this, it seems it's a side effect of XPath requiring an IEEE double representation for numbers: http://mail.gnome.org/archives/xml/2002-May/msg00045.html check the thread, it's worth it, seems you may be able to get more control using better format-number args. Daniel
Considering the output of the thread on the list this really is a side effect of the IEEE definition of float operations in XSLT, and there isn't anything which can sanely be done to avoid those rounding effects ... Daniel