> 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
>
