From: Dimitre Novatchev <dnovatchev@gm...>  20070318 18:44:27

> I know that the XPath standard does not require any processor to work > more correct than possible with IEEE 754 arithmetic. I also know that > the underlying language is Java and the JVM will likely have its > constraints. However, I was suprised that the result was influenced by > the math:power function This has nothing to do with math:power. Take for example: 9007199254740995 idiv xs:double(1) the result is: 9007199254740996  Cheers, Dimitre Novatchev  Truly great madness cannot be achieved without significant intelligence.  To invent, you need a good imagination and a pile of junk  You've achieved success in your field when you don't know whether what you're doing is work or play On 3/18/07, Abel Braaksma <abel.online@...> wrote: > Hi List, > > I struggled with some inexplainable errors when calculating from decimal > to hexadecimal in my UUID post on the xsllist: > http://www.biglist.com/lists/xsllist/archives/200703/msg00434.html, for > which I used the math:power EXSLT function of Saxon. In the post, I > resolved the issue explained below with explicit casting of the > math:power result to an xs:integer. > > I used the following functions to test erroneous behavior when I > suspected that math:power(xx, 0) crapped my results: > > <! using power fu that returns 1.0 > > <xsl:function name="f:pwr" as="xs:integer"> > <xsl:param name="nr" /> > <xsl:sequence select="$nr idiv math:power(16, 0)" /> > </xsl:function> > > <! using idiv without power fu > > <xsl:function name="f:dbl" as="xs:integer"> > <xsl:param name="nr" /> > <xsl:sequence select="$nr idiv 1.0" /> > </xsl:function> > > The result of these are equal for all numbers below or equal to > 9007199254740994 (which happens to be 2^53, which happens to be the > highest integer representable in a IEEE754 floating point double > without rounding problems. > > When input is: 9007199254740995 then: > f:pwr >> 9007199254740996 > f:dbl >> 9007199254740995 > > When input is: 13393530584140003 > f:pwr >> 13393530584140004 > f:dbl >> 13393530584140003 > > When input is: 133935305841400005 > f:pwr >> 133935305841400000 > f:dbl >> 133935305841400005 > > > I know that the XPath standard does not require any processor to work > more correct than possible with IEEE 754 arithmetic. I also know that > the underlying language is Java and the JVM will likely have its > constraints. However, I was suprised that the result was influenced by > the math:power function, and that the results are different when using > floating points in another way. I reckoned that math:power(xx, 0) would > return 1.0 (representable as a precise number with floating point > representation) and that any further calculation would equal the > calculations done with the number '1.0' itself. > > I did see some other differences with other values in math:power, but I > did not investigate it too much further. When surrounding the > math:power() with a cast to xs:integer, all problems vanish. I think I > expected the result of math:power(int, int) to be optimized to integer > arithmetic. Not sure whether that is feasible, though. > > Well, Michael, this time I don't have an obscure bug, I just have an > observation that struck me as odd, which isn't wrong or a bug per se, > but may raise questions when anybody encounters it, which is why I felt > to file it to the archives ;) > > Cheers, >  Abel Braaksma > http://www.nuntia.nl > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > saxonhelp mailing list > saxonhelp@... > https://lists.sourceforge.net/lists/listinfo/saxonhelp > 