XML Accuracy Puzzle
-
If I execute the following xslt I get the result given below. I'm no mathematician but 100 times 2500.01 does not equal 250001.00000000003 I can find very little about this on the web and no suggested fixes or solutions. This is causing me a big problem as my entire architecture hangs around xslt. Using VS2008 and have IE8 installed. Can anyone help? Please? <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > <xsl:template match="/"> <res> <xsl:value-of select="2500.01 * 100"/> </res> </xsl:template> </xsl:stylesheet> <?xml version="1.0" encoding="utf-8"?> <res>250001.00000000003</res>
-
If I execute the following xslt I get the result given below. I'm no mathematician but 100 times 2500.01 does not equal 250001.00000000003 I can find very little about this on the web and no suggested fixes or solutions. This is causing me a big problem as my entire architecture hangs around xslt. Using VS2008 and have IE8 installed. Can anyone help? Please? <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > <xsl:template match="/"> <res> <xsl:value-of select="2500.01 * 100"/> </res> </xsl:template> </xsl:stylesheet> <?xml version="1.0" encoding="utf-8"?> <res>250001.00000000003</res>
Not strictly an XSLT problem - it's more that IEEE754 floating-point isn't completely accurate, especially with things like .1 or .01, as they are irrational when expressed in binary. For example - I just tried your example with both Python[^] and ghci[^] (a Haskell[^] REPL), and they gave the same answer as you got.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Not strictly an XSLT problem - it's more that IEEE754 floating-point isn't completely accurate, especially with things like .1 or .01, as they are irrational when expressed in binary. For example - I just tried your example with both Python[^] and ghci[^] (a Haskell[^] REPL), and they gave the same answer as you got.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
On another forum (I know naughty) I got this response: Well XPath 1.0 uses double floating point numbers like JavaScript or Java do too and with these there is limited precision, in particular when there is no finite binary representation of a number. With XSLT 1.0 you can use format-number to ensure you get a certain number of decimal positions. Or you need to change to XPath 2.0 (as implemented by Saxon 9) and use xs:decimal numbers instead of double numbers. -- Martin Honnen --- MVP XML http://msmvps.com/blogs/martin\_honnen/ Thanks Martin ;-)
-
On another forum (I know naughty) I got this response: Well XPath 1.0 uses double floating point numbers like JavaScript or Java do too and with these there is limited precision, in particular when there is no finite binary representation of a number. With XSLT 1.0 you can use format-number to ensure you get a certain number of decimal positions. Or you need to change to XPath 2.0 (as implemented by Saxon 9) and use xs:decimal numbers instead of double numbers. -- Martin Honnen --- MVP XML http://msmvps.com/blogs/martin\_honnen/ Thanks Martin ;-)
contactowen wrote:
On another forum (I know naughty)
Indeed - consider your CP membership revoked!!! :-D
contactowen wrote:
With XSLT 1.0 you can use format-number to ensure you get a certain number of decimal positions.
Quite true - I wasn't aware of that function until you mentioned it :-O
contactowen wrote:
Or you need to change to XPath 2.0 (as implemented by Saxon 9) and use xs:decimal numbers instead of double numbers.
Also true (in the commercial version of Saxon, anyway - I don't think the free one supports XML Schema datatypes) - I presumed that you would be using MSXML, in which case XPath 2.0 and XSLT 2.0 aren't really an option.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p