Error/Bug adding floating point numbers

[Daniel Thommes <D....@gmx.net>]

Hello,

I think to have found a bug in Xalan-J 2.7.0 when adding floating point numbers:

My XML-File:

<?xml version="1.0" encoding="UTF-8"?>
<values>
  <x>2.33</x>
  <y>2.001</y>
</values>


My XSLT-File:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
	<xsl:template match="/values">
		<results>
			<sum>
				<xsl:value-of select="x + y"/>
			</sum>
			<diff>
				<xsl:value-of select="x - y"/>
			</diff>
		</results>
	</xsl:template>
</xsl:stylesheet>


The result procuced by Xalan:

<?xml version="1.0" encoding="UTF-8"?>
<results>
	<sum>4.3309999999999995</sum>
	<diff>0.3290000000000002</diff>
</results>

I know, that the error is very small, but because in a later step I will round those numbers, it is likely that there will happen bigger errors thinking of worst case.

Any suggestions how to fix this problem? Do you think, I should open an issue for this?

Greetings

Daniel


-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

RE: Error/Bug adding floating point numbers

[Timothy Jones <Ti...@syniverse.com>]

I feel your pain, Ambika, really I do...

 

This is the reason my output stylesheets are riddled with
format-number().

 

        <xsl:value-of select="format-number(number(@AIR_CHARGES),
'#,##0.00')" />

and

        <xsl:variable name='roundedValue'
select='format-number(number($rawValue), "0.00")' />

 

But in my case, I know I am working with dollars/cents, so I know what
my output precision should be.  I fully appreciate that in other cases,
it may not be so clearly defined.

 

The same kind of behavior exists in languages that have 'float' and
'double' types (C, C++, Java, etc, probably Pascal's "real" type too).
To combat this for currency values, I convert them to the biggest
integer type and process them as cents: 32-bit long in "old C", 64-bit
long in Java, and "long long" on modern C/C++ compilers.  At least then
you are in complete control of your math.  Java also has
java.math.BigDecimal which doesn't do the IEEE-754 behavior either, but
it has the overhead of being a java.lang.Object subclass, whereas the
primitive integers/longs work faster.  

 

I have never understood how people can accept this rounding over the
years, but these are my workarounds.

 

 

Timothy  Jones

Syniverse Technologies

Work

(813) 637-5366

Sr. Systems Engineer  

Cell

(813) 857-7650

Development, Tampa, FL

 

Re: Error/Bug adding floating point numbers

[ke...@us.ibm.com]

Decimal numbers to not always have an exact representation in IEEE 754
floating point binary. Roundoff is expected and accepted. Websearch on
"floating point round" will find much discussion.

If we're rounding in ways that don't agree with that spec, there's a
problem... but I'd be shocked if that was the case.

______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
  -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish
(http://www.ovff.org/pegasus/songs/threes-rev-11.html)