From: Dimitre Novatchev <dnovatchev@gm...>  20090114 04:27:41

Hi, The following transformation, performed with Saxon 9.1.0.1J: <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:saxon="http://saxon.sf.net/"; xmlns:f="http://fxsl.sf.net/"; excluderesultprefixes="xs saxon f" > <xsl:output method="text"/> <xsl:template name="initial" match="/*"> <xsl:valueof select="f:pow2mod(7427466390, 7427466391)"/> </xsl:template> <xsl:function name="f:pow2mod" as="xs:decimal"> <xsl:param name="pE" as="xs:decimal"/> <xsl:param name="pN" as="xs:decimal"/> <xsl:variable name="vE" select="xs:decimal($pE)"/> <xsl:variable name="vN" select="xs:decimal($pN)"/> <! <xsl:sequence select= "if($pE eq 1) then 2 else for $half in f:pow2mod($pE idiv 2, $pN) return $half * $half * (1 + ($pE mod 2)) mod $pN "/> > <! > <xsl:sequence select= "if($vE eq 1) then 2 else for $half in f:pow2mod($vE idiv 2, $vN) return $half * $half * (1 + ($vE mod 2)) mod $vN "/> </xsl:function> </xsl:stylesheet> produces result: 1 However, when the first <xsl:sequence> is uncommented and the second is commented, the result is: 2954395288 The correct result in both cases must be: 1 The only difference b/n the two expressions is that: The first uses $pE and $pN, which are of type xs:decimal, but the actual arguments passed are (I suppose, of type xs:integer); The second uses $vE and $vN, which are constructed using xs:decimal() respectively from $pE and $pN. This shows that there are the following two bugs: In the implementation of the "mod" operator for BigInteger, or in the implementation of multiplication of BigInteger(s) In (not) converting the actual argument to the declared type of the formal argument  xs:decimal (I know that every xs:integer is an xs:decimal, however if this conversion had been carried out the previous bug would have been avoided, at least for smaller values). I would greatly appreciate any recommendations for a workaround and, of course, a more permanent fix.  Cheers, Dimitre Novatchev  Truly great madness cannot be achieved without significant intelligence.  To invent, you need a good imagination and a pile of junk  Never fight an inanimate object  You've achieved success in your field when you don't know whether what you're doing is work or play 
Re: [saxon] Bug in xs:integer mod or multiplication (and
probablyanother bug in argument conversion)
From: Michael Kay <mike@sa...>  20090114 13:49:28

Thanks for reporting this, I will look at it tomorrow when I am back in the office. Michael Kay http://www.saxonica.com/ > Original Message > From: Dimitre Novatchev [mailto:dnovatchev@...] > Sent: 14 January 2009 04:28 > To: Mailing list for the SAXON XSLT and XQuery processor > Cc: Dimitre Novatchev > Subject: [saxon] Bug in xs:integer mod or multiplication (and > probablyanother bug in argument conversion) > > Hi, > > The following transformation, performed with Saxon 9.1.0.1J: > > <xsl:stylesheet version="2.0" > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > xmlns:xs="http://www.w3.org/2001/XMLSchema"; > xmlns:saxon="http://saxon.sf.net/"; > xmlns:f="http://fxsl.sf.net/"; > excluderesultprefixes="xs saxon f" > > > > <xsl:output method="text"/> > > <xsl:template name="initial" match="/*"> > > > <xsl:valueof select="f:pow2mod(7427466390, 7427466391)"/> > </xsl:template> > > <xsl:function name="f:pow2mod" as="xs:decimal"> > <xsl:param name="pE" as="xs:decimal"/> > <xsl:param name="pN" as="xs:decimal"/> > > <xsl:variable name="vE" select="xs:decimal($pE)"/> > <xsl:variable name="vN" select="xs:decimal($pN)"/> > > <! > <xsl:sequence select= > "if($pE eq 1) > then 2 > else > for $half in f:pow2mod($pE idiv 2, $pN) > return > $half * $half * (1 + ($pE mod 2)) mod $pN > > "/> > > > <! > > <xsl:sequence select= > "if($vE eq 1) > then 2 > else > for $half in f:pow2mod($vE idiv 2, $vN) > return > $half * $half * (1 + ($vE mod 2)) mod $vN > > "/> > > </xsl:function> > </xsl:stylesheet> > > produces result: > > 1 > > However, when the first <xsl:sequence> is uncommented and the > second is commented, the result is: > > 2954395288 > > The correct result in both cases must be: 1 > > The only difference b/n the two expressions is that: > The first uses $pE and $pN, which are of type xs:decimal, > but the actual arguments passed are (I suppose, of type xs:integer); > The second uses $vE and $vN, which are constructed using > xs:decimal() respectively from $pE and $pN. > > This shows that there are the following two bugs: > In the implementation of the "mod" operator for > BigInteger, or in the implementation of multiplication of > BigInteger(s) > In (not) converting the actual argument to the declared > type of the formal argument  xs:decimal (I know that every > xs:integer is an xs:decimal, however if this conversion had > been carried out the previous bug would have been avoided, at > least for smaller values). > > > I would greatly appreciate any recommendations for a > workaround and, of course, a more permanent fix. > >  > Cheers, > Dimitre Novatchev >  > Truly great madness cannot be achieved without significant > intelligence. >  > To invent, you need a good imagination and a pile of junk >  > Never fight an inanimate object >  > You've achieved success in your field when you don't know > whether what you're doing is work or play > >  >  > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sfspreadtheword > _______________________________________________ > saxonhelp mailing list archived at > http://saxon.markmail.org/ saxonhelp@... > https://lists.sourceforge.net/lists/listinfo/saxonhelp 
From: ac <ac@hy...>  20090114 16:50:02

Hi Michael and Everyone, Sorry to take your time. I am wandering what it would take to interface Saxon XSLT to eXist so that all XSLT file/stream I/O operations like doc(), document(), collection(), resultdocument can access eXist collections directly, for example, simply by replacing the url (e.g. url protocol) to refer to eXist; ensuring that the stylesheet code does not have to be changed when moving from files to dbcollections and back? Thank you. Cheers, ac 
From: Michael Kay <mike@sa...>  20090115 09:20:35

> > I am wandering what it would take to interface Saxon XSLT to > eXist so that all XSLT file/stream I/O operations like doc(), > document(), collection(), resultdocument can access eXist > collections directly, for example, simply by replacing the > url (e.g. url protocol) to refer to eXist; ensuring that the > stylesheet code does not have to be changed when moving from > files to dbcollections and back? At a basic level you could do that by writing a couple of URIResolvers. However, I don't think that interfacing Saxon to an XML database at this level would really meet user requirements. What people really want is for the XSLT or XQuery processor to take advantage of persistent indexes maintained in the database, and that is quite a bit more difficult. What is really needed here is for Saxon to access an external data source at the XQuery level. That's a fair bit of work. Michael Kay Saxonica 
Re: [saxon] Bug in xs:integer mod or multiplication (and
probablyanother bug in argument conversion)
From: Michael Kay <mike@sa...>  20090115 15:35:04

The bug occurs when multiplying two integers whose absolute values are both between 2^31 and 2^32. The result comes out as a large negative number. I've logged this as bug 2510104, and a patch for the 9.1 branch is in Subversion. There's no bug in argument conversion: an instance of xs:integer is an instance of xs:decimal, so there is no need to do any conversion when an xs:integer is supplied and an xs:decimal is required. In fact it would be incorrect to do so: the expression ($param instance of xs:integer) in this situation is defined to return true(). Michael Kay http://www.saxonica.com/ > Original Message > From: Dimitre Novatchev [mailto:dnovatchev@...] > Sent: 14 January 2009 04:28 > To: Mailing list for the SAXON XSLT and XQuery processor > Cc: Dimitre Novatchev > Subject: [saxon] Bug in xs:integer mod or multiplication (and > probablyanother bug in argument conversion) > > Hi, > > The following transformation, performed with Saxon 9.1.0.1J: > > <xsl:stylesheet version="2.0" > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > xmlns:xs="http://www.w3.org/2001/XMLSchema"; > xmlns:saxon="http://saxon.sf.net/"; > xmlns:f="http://fxsl.sf.net/"; > excluderesultprefixes="xs saxon f" > > > > <xsl:output method="text"/> > > <xsl:template name="initial" match="/*"> > > > <xsl:valueof select="f:pow2mod(7427466390, 7427466391)"/> > </xsl:template> > > <xsl:function name="f:pow2mod" as="xs:decimal"> > <xsl:param name="pE" as="xs:decimal"/> > <xsl:param name="pN" as="xs:decimal"/> > > <xsl:variable name="vE" select="xs:decimal($pE)"/> > <xsl:variable name="vN" select="xs:decimal($pN)"/> > > <! > <xsl:sequence select= > "if($pE eq 1) > then 2 > else > for $half in f:pow2mod($pE idiv 2, $pN) > return > $half * $half * (1 + ($pE mod 2)) mod $pN > > "/> > > > <! > > <xsl:sequence select= > "if($vE eq 1) > then 2 > else > for $half in f:pow2mod($vE idiv 2, $vN) > return > $half * $half * (1 + ($vE mod 2)) mod $vN > > "/> > > </xsl:function> > </xsl:stylesheet> > > produces result: > > 1 > > However, when the first <xsl:sequence> is uncommented and the > second is commented, the result is: > > 2954395288 > > The correct result in both cases must be: 1 > > The only difference b/n the two expressions is that: > The first uses $pE and $pN, which are of type xs:decimal, > but the actual arguments passed are (I suppose, of type xs:integer); > The second uses $vE and $vN, which are constructed using > xs:decimal() respectively from $pE and $pN. > > This shows that there are the following two bugs: > In the implementation of the "mod" operator for > BigInteger, or in the implementation of multiplication of > BigInteger(s) > In (not) converting the actual argument to the declared > type of the formal argument  xs:decimal (I know that every > xs:integer is an xs:decimal, however if this conversion had > been carried out the previous bug would have been avoided, at > least for smaller values). > > > I would greatly appreciate any recommendations for a > workaround and, of course, a more permanent fix. > >  > Cheers, > Dimitre Novatchev >  > Truly great madness cannot be achieved without significant > intelligence. >  > To invent, you need a good imagination and a pile of junk >  > Never fight an inanimate object >  > You've achieved success in your field when you don't know > whether what you're doing is work or play > >  >  > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sfspreadtheword > _______________________________________________ > saxonhelp mailing list archived at > http://saxon.markmail.org/ saxonhelp@... > https://lists.sourceforge.net/lists/listinfo/saxonhelp 
Re: [saxon] Bug in xs:integer mod or multiplication (and
probablyanother bug in argument conversion)
From: Dimitre Novatchev <dnovatchev@gm...>  20090115 17:13:09

Thank you, that's a stellar response!  Cheers, Dimitre Novatchev  Truly great madness cannot be achieved without significant intelligence.  To invent, you need a good imagination and a pile of junk  Never fight an inanimate object  You've achieved success in your field when you don't know whether what you're doing is work or play On Thu, Jan 15, 2009 at 7:34 AM, Michael Kay <mike@...> wrote: > The bug occurs when multiplying two integers whose absolute values are both > between 2^31 and 2^32. The result comes out as a large negative number. I've > logged this as bug 2510104, and a patch for the 9.1 branch is in Subversion. > > There's no bug in argument conversion: an instance of xs:integer is an > instance of xs:decimal, so there is no need to do any conversion when an > xs:integer is supplied and an xs:decimal is required. In fact it would be > incorrect to do so: the expression ($param instance of xs:integer) in this > situation is defined to return true(). > > Michael Kay > http://www.saxonica.com/ > >> Original Message >> From: Dimitre Novatchev [mailto:dnovatchev@...] >> Sent: 14 January 2009 04:28 >> To: Mailing list for the SAXON XSLT and XQuery processor >> Cc: Dimitre Novatchev >> Subject: [saxon] Bug in xs:integer mod or multiplication (and >> probablyanother bug in argument conversion) >> >> Hi, >> >> The following transformation, performed with Saxon 9.1.0.1J: >> >> <xsl:stylesheet version="2.0" >> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; >> xmlns:xs="http://www.w3.org/2001/XMLSchema"; >> xmlns:saxon="http://saxon.sf.net/"; >> xmlns:f="http://fxsl.sf.net/"; >> excluderesultprefixes="xs saxon f" >> > >> >> <xsl:output method="text"/> >> >> <xsl:template name="initial" match="/*"> >> >> >> <xsl:valueof select="f:pow2mod(7427466390, 7427466391)"/> >> </xsl:template> >> >> <xsl:function name="f:pow2mod" as="xs:decimal"> >> <xsl:param name="pE" as="xs:decimal"/> >> <xsl:param name="pN" as="xs:decimal"/> >> >> <xsl:variable name="vE" select="xs:decimal($pE)"/> >> <xsl:variable name="vN" select="xs:decimal($pN)"/> >> >> <! >> <xsl:sequence select= >> "if($pE eq 1) >> then 2 >> else >> for $half in f:pow2mod($pE idiv 2, $pN) >> return >> $half * $half * (1 + ($pE mod 2)) mod $pN >> >> "/> >> > >> <! > >> <xsl:sequence select= >> "if($vE eq 1) >> then 2 >> else >> for $half in f:pow2mod($vE idiv 2, $vN) >> return >> $half * $half * (1 + ($vE mod 2)) mod $vN >> >> "/> >> >> </xsl:function> >> </xsl:stylesheet> >> >> produces result: >> >> 1 >> >> However, when the first <xsl:sequence> is uncommented and the >> second is commented, the result is: >> >> 2954395288 >> >> The correct result in both cases must be: 1 >> >> The only difference b/n the two expressions is that: >> The first uses $pE and $pN, which are of type xs:decimal, >> but the actual arguments passed are (I suppose, of type xs:integer); >> The second uses $vE and $vN, which are constructed using >> xs:decimal() respectively from $pE and $pN. >> >> This shows that there are the following two bugs: >> In the implementation of the "mod" operator for >> BigInteger, or in the implementation of multiplication of >> BigInteger(s) >> In (not) converting the actual argument to the declared >> type of the formal argument  xs:decimal (I know that every >> xs:integer is an xs:decimal, however if this conversion had >> been carried out the previous bug would have been avoided, at >> least for smaller values). >> >> >> I would greatly appreciate any recommendations for a >> workaround and, of course, a more permanent fix. >> >>  >> Cheers, >> Dimitre Novatchev >>  >> Truly great madness cannot be achieved without significant >> intelligence. >>  >> To invent, you need a good imagination and a pile of junk >>  >> Never fight an inanimate object >>  >> You've achieved success in your field when you don't know >> whether what you're doing is work or play >> >>  >>  >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sfspreadtheword >> _______________________________________________ >> saxonhelp mailing list archived at >> http://saxon.markmail.org/ saxonhelp@... >> https://lists.sourceforge.net/lists/listinfo/saxonhelp > > >  > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sfspreadtheword > _______________________________________________ > saxonhelp mailing list archived at http://saxon.markmail.org/ > saxonhelp@... > https://lists.sourceforge.net/lists/listinfo/saxonhelp > 
From: ac <ac@hy...>  20090115 15:36:21

Hi Michael, Thank you. Yes, efficient indexes and queries are important. It sounds like a nice thing for Saxon and XSLT, anyway. Thanks. Cheers, ac >> I am wandering what it would take to interface Saxon XSLT to >> eXist so that all XSLT file/stream I/O operations like doc(), >> document(), collection(), resultdocument can access eXist >> collections directly, for example, simply by replacing the >> url (e.g. url protocol) to refer to eXist; ensuring that the >> stylesheet code does not have to be changed when moving from >> files to dbcollections and back? >> > > At a basic level you could do that by writing a couple of URIResolvers. > > However, I don't think that interfacing Saxon to an XML database at this > level would really meet user requirements. What people really want is for > the XSLT or XQuery processor to take advantage of persistent indexes > maintained in the database, and that is quite a bit more difficult. > > What is really needed here is for Saxon to access an external data source at > the XQuery level. That's a fair bit of work. > > Michael Kay > Saxonica > > >  > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sfspreadtheword > _______________________________________________ > saxonhelp mailing list archived at http://saxon.markmail.org/ > saxonhelp@... > https://lists.sourceforge.net/lists/listinfo/saxonhelp > > 