Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(5) 
_{Jul}
(103) 
_{Aug}
(139) 
_{Sep}
(120) 
_{Oct}
(108) 
_{Nov}
(83) 
_{Dec}
(83) 

2002 
_{Jan}
(124) 
_{Feb}
(94) 
_{Mar}
(66) 
_{Apr}
(71) 
_{May}
(94) 
_{Jun}
(71) 
_{Jul}
(155) 
_{Aug}
(96) 
_{Sep}
(64) 
_{Oct}
(73) 
_{Nov}
(79) 
_{Dec}
(53) 
2003 
_{Jan}
(82) 
_{Feb}
(76) 
_{Mar}
(98) 
_{Apr}
(142) 
_{May}
(133) 
_{Jun}
(120) 
_{Jul}
(72) 
_{Aug}
(136) 
_{Sep}
(169) 
_{Oct}
(113) 
_{Nov}
(149) 
_{Dec}
(76) 
2004 
_{Jan}
(120) 
_{Feb}
(195) 
_{Mar}
(215) 
_{Apr}
(171) 
_{May}
(189) 
_{Jun}
(221) 
_{Jul}
(107) 
_{Aug}
(107) 
_{Sep}
(94) 
_{Oct}
(145) 
_{Nov}
(116) 
_{Dec}
(198) 
2005 
_{Jan}
(153) 
_{Feb}
(163) 
_{Mar}
(164) 
_{Apr}
(157) 
_{May}
(134) 
_{Jun}
(173) 
_{Jul}
(63) 
_{Aug}
(175) 
_{Sep}
(136) 
_{Oct}
(150) 
_{Nov}
(192) 
_{Dec}
(99) 
2006 
_{Jan}
(94) 
_{Feb}
(109) 
_{Mar}
(191) 
_{Apr}
(146) 
_{May}
(184) 
_{Jun}
(160) 
_{Jul}
(128) 
_{Aug}
(206) 
_{Sep}
(123) 
_{Oct}
(133) 
_{Nov}
(204) 
_{Dec}
(103) 
2007 
_{Jan}
(304) 
_{Feb}
(191) 
_{Mar}
(281) 
_{Apr}
(127) 
_{May}
(102) 
_{Jun}
(147) 
_{Jul}
(153) 
_{Aug}
(156) 
_{Sep}
(52) 
_{Oct}
(119) 
_{Nov}
(138) 
_{Dec}
(128) 
2008 
_{Jan}
(214) 
_{Feb}
(151) 
_{Mar}
(221) 
_{Apr}
(146) 
_{May}
(192) 
_{Jun}
(93) 
_{Jul}
(270) 
_{Aug}
(127) 
_{Sep}
(161) 
_{Oct}
(110) 
_{Nov}
(189) 
_{Dec}
(142) 
2009 
_{Jan}
(123) 
_{Feb}
(136) 
_{Mar}
(139) 
_{Apr}
(138) 
_{May}
(90) 
_{Jun}
(74) 
_{Jul}
(77) 
_{Aug}
(159) 
_{Sep}
(95) 
_{Oct}
(154) 
_{Nov}
(131) 
_{Dec}
(120) 
2010 
_{Jan}
(118) 
_{Feb}
(148) 
_{Mar}
(208) 
_{Apr}
(100) 
_{May}
(99) 
_{Jun}
(129) 
_{Jul}
(115) 
_{Aug}
(72) 
_{Sep}
(124) 
_{Oct}
(133) 
_{Nov}
(64) 
_{Dec}
(101) 
2011 
_{Jan}
(104) 
_{Feb}
(125) 
_{Mar}
(107) 
_{Apr}
(59) 
_{May}
(56) 
_{Jun}
(115) 
_{Jul}
(86) 
_{Aug}
(126) 
_{Sep}
(100) 
_{Oct}
(98) 
_{Nov}
(112) 
_{Dec}
(129) 
2012 
_{Jan}
(110) 
_{Feb}
(124) 
_{Mar}
(150) 
_{Apr}
(96) 
_{May}
(80) 
_{Jun}
(103) 
_{Jul}
(35) 
_{Aug}
(89) 
_{Sep}
(97) 
_{Oct}
(54) 
_{Nov}
(58) 
_{Dec}
(95) 
2013 
_{Jan}
(106) 
_{Feb}
(108) 
_{Mar}
(81) 
_{Apr}
(100) 
_{May}
(122) 
_{Jun}
(93) 
_{Jul}
(77) 
_{Aug}
(73) 
_{Sep}
(166) 
_{Oct}
(88) 
_{Nov}
(61) 
_{Dec}
(142) 
2014 
_{Jan}
(110) 
_{Feb}
(98) 
_{Mar}
(63) 
_{Apr}
(47) 
_{May}
(73) 
_{Jun}
(103) 
_{Jul}
(81) 
_{Aug}
(30) 
_{Sep}
(65) 
_{Oct}
(92) 
_{Nov}
(47) 
_{Dec}
(69) 
2015 
_{Jan}
(63) 
_{Feb}
(48) 
_{Mar}
(31) 
_{Apr}
(42) 
_{May}
(30) 
_{Jun}
(80) 
_{Jul}
(38) 
_{Aug}
(3) 
_{Sep}
(43) 
_{Oct}
(56) 
_{Nov}
(43) 
_{Dec}
(51) 
2016 
_{Jan}
(33) 
_{Feb}
(27) 
_{Mar}
(22) 
_{Apr}
(63) 
_{May}
(16) 
_{Jun}
(19) 
_{Jul}
(28) 
_{Aug}
(66) 
_{Sep}
(58) 
_{Oct}
(61) 
_{Nov}
(80) 
_{Dec}
(33) 
2017 
_{Jan}
(8) 
_{Feb}
(41) 
_{Mar}
(36) 
_{Apr}
(26) 
_{May}
(22) 
_{Jun}
(28) 
_{Jul}
(21) 
_{Aug}
(34) 
_{Sep}
(19) 
_{Oct}
(23) 
_{Nov}
(18) 
_{Dec}
(3) 
2018 
_{Jan}
(25) 
_{Feb}
(36) 
_{Mar}
(20) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(6) 
2
(9) 
3

4
(4) 
5
(29) 
6
(20) 
7
(19) 
8
(16) 
9
(5) 
10

11
(5) 
12
(7) 
13
(6) 
14
(11) 
15
(23) 
16
(19) 
17
(1) 
18
(12) 
19
(15) 
20
(12) 
21
(12) 
22
(24) 
23
(2) 
24

25

26

27
(5) 
28
(7) 
29
(4) 
30
(5) 
31
(3) 
From: Abel Braaksma <abel.online@xs...>  20070318 23:55:50

Mark wrote: > I have the following variation on the identity > stylesheet: > > <?xml version="1.0" encoding="UTF8"?> > <xsl:stylesheet > xmlns="http://www.w3.org/1999/xhtml"; > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > version="2.0"> > <xsl:output method="html"/> > <xsl:template match="node()@*"> > <xsl:copy> > <xsl:applytemplates select="node()@*"/> > </xsl:copy> > </xsl:template> > <xsl:template match="table"/> > </xsl:stylesheet> Your code looks fine to me. I tried it, and strangely, it worked the same way here with your beloved table showing up. I also tried xpathdefaultnamespace, but to no luck either. What does work, however, is getting it out of the default namespace (not in the source, but in your xslt): <xsl:stylesheet xmlns:xhtml="http://www.w3.org/1999/xhtml"; and then, adjust your matches accordingly: <xsl:template match="xhtml:table" /> But I must be missing something, because that should work the same as, say: <xsl:template match="table" xpathdefaultnamespace="http://www.w3.org/1999/xhtml"/>; but it doesn't. Adding some other namespaces to your source showed the same behavior, meaning it doesn't matter if it's the xhtml namespace or not. Weird, because I have plenty of code where I use xpathdefaultnamespace and it does work... I just couldn't get it to work with your source... :S (I hope it is just the late hour and tomorrow I'll see what it should be ;)  Abel 
From: Wayne Chan <Wayne.Chan@Sun.COM>  20070318 23:36:59

hi michael, here is the complete files for the xinclude not working example:  > more xi_saxon.xml <abc> <test> <xi:include href="lt/dat/uplt_fog_weekfile.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>; </test> </abc> > more lt/dat/uplt_fog_weekfile.xml <fogs> <fog_stats name="sguplt01"> <xi:include parse="xml" href="sguplt01_weekfile.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>; </fog_stats> </fogs> > ./saxon.sh xi_saxon.xml xi.xsl Error on line 3 column 101 of file:/worktone/20079999/lt/dat/uplt_fog_weekfile.xml: SXXP0003: Error reported by XML parser: The prefix "xi" for element "xi:include" is not bound. Error on line 3 column 93 of file:/worktone/20079999/xi_saxon.xml: SXXP0003: Error reported by XML parser: Error attempting to parse XML file (href='lt/dat/uplt_fog_weekfile.xml'). Transformation failed: Runtime errors were reported >  btw, i have both your xslt books (xslt 1.0 and xslt 2.0). it has been a musthave desk side reference for me.. thanks, Wayne Chan ( X81270 / 4084048588) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Sat, 17 Mar 2007, Michael Kay wrote: < MK >> the xi_saxon.xml file is added a top level elemnts <abc> .. < MK >> </abc> above <test> .. </test> then xinclude failed with the < MK >> following error message! not sure it is saxon problem or xml < MK >> xinclude problem.. < MK > < MK >Saxon is just reporting the error message that comes from the XML parser. < MK >(Don't blame the messenger!) < MK > < MK >In this case the error message < MK > < MK >> Error on line 3 column 101 of < MK >> file:/worktone/20079999/lt/dat/uplt_fog_weekfile.xml: < MK >> SXXP0003: Error reported by XML parser: The prefix "xi" for < MK >> element "xi:include" is not bound. < MK > < MK >relates to the file being included, which you haven't actually shown us. < MK > < MK >Michael Kay < MK >http://www.saxonica.com/ < MK > < MK > 
From: Abel Braaksma <abel.online@xs...>  20070318 23:28:38

Dimitre Novatchev wrote: > This has nothing to do with math:power. > > Take for example: > > 9007199254740995 idiv xs:double(1) > > the result is: > > 9007199254740996 I see now, thanks. I used 1.0 as comparison, which is an xs:decimal (though I thought it was an xs:double, I need to reread my textbook, I think).  Abel 
From: Abel Braaksma <abel.online@xs...>  20070318 23:25:25

Michael Kay wrote: > If you don't want rounding errors for numbers with more than 16 digits, then > don't use xs:double arithmetic, which is defined to work with a given > precision (Saxon doesn't even have the option of using higher precision). > Work instead with xs:integer or xs:decimal. > > The EXSLT math library is defined to work on xs:double as that's the only > thing that was available in XSLT 1.0. One could define a similar library for > xs:decimal or xs:integer, though I'm not sure which of the functions would > be needed  I can't see anyone except numerical analysts wanting > trigonometry functions in xs:decimal. Thanks for the clarification, I'll consider xs:decimal more often. I see now that I was focused on xs:double / xs:float as being the counterparts of their IEEE 754 equivalents, and that, when using just '1.0' instead, I unconsciously used an xs:decimal (where I thought that the correct outcome was due to optimization to xs:integer or something). About trigonometry, you are probably right, except that making charts in SVG might be a common task for XSLT, though I guess that float/double will give enough precision. However, with math:power as an aid for calculating hex/dec/bin/oct conversions of any kind, 16digit dec numbers will suffer from this rounding error. But of course, there are easy and plenty workarounds.  Abel 
From: Mark <mark6139@ya...>  20070318 23:22:08

I have the following variation on the identity stylesheet: <?xml version="1.0" encoding="UTF8"?> <xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml"; xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version="2.0"> <xsl:output method="html"/> <xsl:template match="node()@*"> <xsl:copy> <xsl:applytemplates select="node()@*"/> </xsl:copy> </xsl:template> <xsl:template match="table"/> </xsl:stylesheet> Applying this stylesheet (using Saxon 8) does not remove the table from the following source document as expected:  <html lang="enUS" xml:lang="enUS" xmlns="http://www.w3.org/1999/xhtml">; <head></head> <body> <p>Hello world.</p> <table><tr><td>I hate this table.</td></tr></table> </body> </html>  I am using the latest version of Saxon 8. If I remove the xmlns attribute from the source document, it removes the table, as expected (this is not a good solution since in my actual application I don't have complete control over the input). Is there a way that I can modify my stylesheet to make it remove the table as in this example? Thanks, Mark ____________________________________________________________________________________ Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather 
From: Dimitre Novatchev <dnovatchev@gm...>  20070318 20:18:12

On a slightly different topic, I don't see any reason why in XSLT 2.0 someone would use the math:power() function of EXSLT and not the f:pow() function of FXSL. Here's a quick benchmark comparison calculating 1.0000000001 ^ 10000000000 math:power(1.0000000001, 10000000000) = 2.7182820532347876 Exact result (the constant e) = 2.71828182845904 f:pow(1.0000000001, 10000000000) = 2.7182820332586624 As we can see, f:pow() produces a slightly more precise result than math:power(). Execution times were roughly the same: 15ms to 26ms for both functions, as measured with the t 3 option by SaxonJ 8.9.2. Certainly, using FXSL has the advantage of not being dependent on the vendor of a particular XSLT processor. Let's take another example: (2 div 3) ^ 1000 math:power((2 div 3),1000) = 8.104774656527117E177 Exact result (using Win calc) = 8.1047746565275666704842658632857e177 f:pow(2 div 3, 1000) = 8.104774656527345E177 Once again, the preciseness of f:pow() is slightly better. The time it takes to calculate this 1000 times and produce the last result is almost the same: 26 to 36 milliseconds. Certainly, there will be examples of calculations done faster with EXSLT, however in most cases hairsplitting speed is not more important than preciseness and vendor independence.  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 > 
From: Michael Kay <mike@sa...>  20070318 19:53:26

This is some kind of version conflict  the various Jar files aren't compatible. Check what version of everything you are using. =20 Michael Kay http://www.saxonica.com/ _____ =20 From: saxonhelpbounces@... [mailto:saxonhelpbounces@...] On Behalf Of Luc = Cessieux Sent: 18 March 2007 08:01 To: saxonhelp@... Subject: [saxon] problem witn attribute in xquery I use nux.jar with the last saxon8.jar et xom.jar and when I execute a Xquery query with attribut search sample: //a[myattribut=3D'toto'] I have the fatal error next. Exception in thread <mailto:saxonhelp@...> "AWTEventQueue0" java.lang.AbstractMethodError: net.sf.saxon.xom.NodeWrapper$AttributeAxisIterator.moveNext()Z at net.sf.saxon.expr.AxisAtomizingIterator.next(AxisAtomizingIterator.java:4= 2) at net.sf.saxon.expr.QuantifiedExpression.effectiveBooleanValue(QuantifiedEx= pre ssion.java:158) at net.sf.saxon.expr.FilterIterator$NonNumeric.matches(FilterIterator.java:1= 78) at net.sf.saxon.expr.FilterIterator.getNextMatchingItem(FilterIterator.java:= 69) at net.sf.saxon.expr.FilterIterator.next(FilterIterator.java:49) at net.sf.saxon.expr.ContextMappingIterator.next(ContextMappingIterator.java= :59 ) at net.sf.saxon.query.XQueryExpression$ErrorReportingIterator.next(XQueryExp= res sion.java:553) at nux.xom.xquery.DefaultResultSequence.next(DefaultResultSequence.java:140)= Thank you very much for uour help _____ =20 Essayez Live.com, votre nouvelle page d'accueil ! Personnalisezla en quelques clics pour retrouver tout ce qui vous int=E9resse au m=EAme = endroit. au m=EAme endroit. <http://www.live.com/getstarted>; =20 
From: Michael Kay <mike@sa...>  20070318 19:50:59

This is _____ =20 From: saxonhelpbounces@... [mailto:saxonhelpbounces@...] On Behalf Of Luc = Cessieux Sent: 18 March 2007 08:01 To: saxonhelp@... Subject: [saxon] problem witn attribute in xquery I use nux.jar with the last saxon8.jar et xom.jar and when I execute a Xquery query with attribut search sample: //a[myattribut=3D'toto'] I have the fatal error next. Exception in thread <mailto:saxonhelp@...> "AWTEventQueue0" java.lang.AbstractMethodError: net.sf.saxon.xom.NodeWrapper$AttributeAxisIterator.moveNext()Z at net.sf.saxon.expr.AxisAtomizingIterator.next(AxisAtomizingIterator.java:4= 2) at net.sf.saxon.expr.QuantifiedExpression.effectiveBooleanValue(QuantifiedEx= pre ssion.java:158) at net.sf.saxon.expr.FilterIterator$NonNumeric.matches(FilterIterator.java:1= 78) at net.sf.saxon.expr.FilterIterator.getNextMatchingItem(FilterIterator.java:= 69) at net.sf.saxon.expr.FilterIterator.next(FilterIterator.java:49) at net.sf.saxon.expr.ContextMappingIterator.next(ContextMappingIterator.java= :59 ) at net.sf.saxon.query.XQueryExpression$ErrorReportingIterator.next(XQueryExp= res sion.java:553) at nux.xom.xquery.DefaultResultSequence.next(DefaultResultSequence.java:140)= Thank you very much for uour help _____ =20 Essayez Live.com, votre nouvelle page d'accueil ! Personnalisezla en quelques clics pour retrouver tout ce qui vous int=E9resse au m=EAme = endroit. au m=EAme endroit. <http://www.live.com/getstarted>; =20 
From: Michael Kay <mike@sa...>  20070318 19:10:23

If you don't want rounding errors for numbers with more than 16 digits, then don't use xs:double arithmetic, which is defined to work with a given precision (Saxon doesn't even have the option of using higher precision). Work instead with xs:integer or xs:decimal. The EXSLT math library is defined to work on xs:double as that's the only thing that was available in XSLT 1.0. One could define a similar library for xs:decimal or xs:integer, though I'm not sure which of the functions would be needed  I can't see anyone except numerical analysts wanting trigonometry functions in xs:decimal. Michael Kay http://www.saxonica.com/ > Original Message > From: saxonhelpbounces@... > [mailto:saxonhelpbounces@...] On Behalf > Of Abel Braaksma > Sent: 18 March 2007 17:56 > To: Mailing list for SAXON XSLT queries > Subject: [saxon] Unexpected rounding problems with > math:power(x, 0) and idiv with idivoperand gt 2^53 > > 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 
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 > 
From: Abel Braaksma <abel.online@xs...>  20070318 17:57:34

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 
From: Luc Cessieux <cessieux@ho...>  20070318 08:01:17

I use nux.jar with the last saxon8.jar et xom.jar and when I execute a Xque= ry query with attribut search sample://a[myattribut=3D'toto']I have the fat= al error next.Exception in thread "AWTEventQueue0" java.lang.AbstractMeth= odError: net.sf.saxon.xom.NodeWrapper$AttributeAxisIterator.moveNext()Z = at net.sf.saxon.expr.AxisAtomizingIterator.next(AxisAtomizingIterator.java:= 42) at net.sf.saxon.expr.QuantifiedExpression.effectiveBooleanValue(Quan= tifiedExpression.java:158) at net.sf.saxon.expr.FilterIterator$NonNumeri= c.matches(FilterIterator.java:178) at net.sf.saxon.expr.FilterIterator.g= etNextMatchingItem(FilterIterator.java:69) at net.sf.saxon.expr.FilterIt= erator.next(FilterIterator.java:49) at net.sf.saxon.expr.ContextMappingI= terator.next(ContextMappingIterator.java:59) at net.sf.saxon.query.XQuer= yExpression$ErrorReportingIterator.next(XQueryExpression.java:553) at nu= x.xom.xquery.DefaultResultSequence.next(DefaultResultSequence.java:140)Than= k you very much for uour help _________________________________________________________________ Exprimezvous : cr=E9ez la page d'accueil qui vous ressemble avec Live.com. http://www.live.com/getstarted= 