From: Michael Kay <mhk@mh...>  20030718 18:52:27

What precision did you expect, and why? Note that Saxon is currently following the XPath 1.0 rules in this area. The XPath 2.0 rules for converting doubles to strings are still in flux. XPath 1.0 is very precise about the expected result, and I believe Saxon is doing the correct thing, though I don't have time to prove it to you just now, as I'm about to disappear on vacation. If you think it's wrong, please tell me what you think the right answer is, and why. Michael Kay > Original Message > From: saxonhelpadmin@...=20 > [mailto:saxonhelpadmin@...] On Behalf Of=20 > Margaret Gr=FCnKerr > Sent: 17 July 2003 09:34 > To: saxonhelp@... > Subject: [saxon] xs:double("1.7976931348623157E308") >=20 >=20 > I fished this example out of the NIST test suite. > The XSL file contained: > <xsl:text> > =20 > "xs:double("1.7976931348623157E3 > 08")" > </xsl:text> >=20 > <xsl:valueof=20 > select=3D"xs:double("1.7976931348623157E308")"/> >=20 >=20 > The result had the requested order of magnitude (stringlenght=20 > 310)but the precision was not as I expected: >=20 > "xs:double("1.7976931348623157E308")" >=20 > 17976931348623157081452742373170435679807056752584499659891 > 747680315726078002853876058955863276687817154045895351438246 > 423432132688946418276846754670353751698604991057655128207624 > 549009038932894407586850845513394230458323690322294816580855 > 933212334827479782620414472316873817718091929988125040402618 > 4124858368 >=20 > Yours sincerely Margaret Gr=FCnKerr >=20 >=20 >=20 >=20 >=20 >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a=20 > single machine. WITHOUT REBOOTING! Mix Linux / Windows /=20 > Novell virtual machines at the same time. Free trial click=20 > here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > saxonhelp mailing list > saxonhelp@...=20 > https://lists.sourceforge.net/lists/listinfo/s>; axonhelp >=20 
From: <margaret.gruenkerr@di...>  20030717 08:34:29

I fished this example out of the NIST test suite. The XSL file contained: <xsl:text> "xs:double("1.7976931348623157E308")" </xsl:text> <xsl:valueof select="xs:double("1.7976931348623157E308")"/> The result had the requested order of magnitude (stringlenght 310)but the precision was not as I expected: "xs:double("1.7976931348623157E308")" 17976931348623157081452742373170435679807056752584499659891 747680315726078002853876058955863276687817154045895351438246 423432132688946418276846754670353751698604991057655128207624 549009038932894407586850845513394230458323690322294816580855 933212334827479782620414472316873817718091929988125040402618 4124858368 Yours sincerely Margaret GrünKerr 
From: Michael Kay <mhk@mh...>  20030718 18:52:27

What precision did you expect, and why? Note that Saxon is currently following the XPath 1.0 rules in this area. The XPath 2.0 rules for converting doubles to strings are still in flux. XPath 1.0 is very precise about the expected result, and I believe Saxon is doing the correct thing, though I don't have time to prove it to you just now, as I'm about to disappear on vacation. If you think it's wrong, please tell me what you think the right answer is, and why. Michael Kay > Original Message > From: saxonhelpadmin@...=20 > [mailto:saxonhelpadmin@...] On Behalf Of=20 > Margaret Gr=FCnKerr > Sent: 17 July 2003 09:34 > To: saxonhelp@... > Subject: [saxon] xs:double("1.7976931348623157E308") >=20 >=20 > I fished this example out of the NIST test suite. > The XSL file contained: > <xsl:text> > =20 > "xs:double("1.7976931348623157E3 > 08")" > </xsl:text> >=20 > <xsl:valueof=20 > select=3D"xs:double("1.7976931348623157E308")"/> >=20 >=20 > The result had the requested order of magnitude (stringlenght=20 > 310)but the precision was not as I expected: >=20 > "xs:double("1.7976931348623157E308")" >=20 > 17976931348623157081452742373170435679807056752584499659891 > 747680315726078002853876058955863276687817154045895351438246 > 423432132688946418276846754670353751698604991057655128207624 > 549009038932894407586850845513394230458323690322294816580855 > 933212334827479782620414472316873817718091929988125040402618 > 4124858368 >=20 > Yours sincerely Margaret Gr=FCnKerr >=20 >=20 >=20 >=20 >=20 >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a=20 > single machine. WITHOUT REBOOTING! Mix Linux / Windows /=20 > Novell virtual machines at the same time. Free trial click=20 > here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > saxonhelp mailing list > saxonhelp@...=20 > https://lists.sourceforge.net/lists/listinfo/s>; axonhelp >=20 
From: Michael Kay <mhk@mh...>  20030718 20:37:57

Just to add to my earlier response, note the XML Schema definition of the xs:double data type: The basic =B7value space=B7 of double consists of the values m =D7 2^e, = where m is an integer whose absolute value is less than 2^53, and e is an integer between 1075 and 970, inclusive. It goes on to say that the string "1.7976931348623157E308" should be represented as the closest possible number in this value space. In the case of an exponent such as E308, this number is going to be a large integer, and it is very unlikely that this integer, when output in decimal notation, will end in lots of zeros, which seems to be what you are expecting. In fact, the definition above tells you that the largest negative double is (2^53  1) x 2^970. Michael Kay > Original Message > From: saxonhelpadmin@...=20 > [mailto:saxonhelpadmin@...] On Behalf Of=20 > Michael Kay > Sent: 18 July 2003 19:35 > To: 'Margaret Gr=FCnKerr'; saxonhelp@... > Subject: RE: [saxon] xs:double("1.7976931348623157E308") >=20 >=20 > What precision did you expect, and why? >=20 > Note that Saxon is currently following the XPath 1.0 rules in=20 > this area. The XPath 2.0 rules for converting doubles to=20 > strings are still in flux. XPath 1.0 is very precise about=20 > the expected result, and I believe Saxon is doing the correct=20 > thing, though I don't have time to prove it to you just now,=20 > as I'm about to disappear on vacation. If you think it's=20 > wrong, please tell me what you think the right answer is, and why. >=20 > Michael Kay >=20 > > Original Message > > From: saxonhelpadmin@... > > [mailto:saxonhelpadmin@...] On Behalf Of=20 > > Margaret Gr=FCnKerr > > Sent: 17 July 2003 09:34 > > To: saxonhelp@... > > Subject: [saxon] xs:double("1.7976931348623157E308") > >=20 > >=20 > > I fished this example out of the NIST test suite. > > The XSL file contained: > > <xsl:text> > > =20 > > "xs:double("1.7976931348623157E3 > > 08")" > > </xsl:text> > >=20 > > <xsl:valueof > > select=3D"xs:double("1.7976931348623157E308")"/> > >=20 > >=20 > > The result had the requested order of magnitude (stringlenght > > 310)but the precision was not as I expected: > >=20 > > "xs:double("1.7976931348623157E308")" > >=20 > > 17976931348623157081452742373170435679807056752584499659891 > > 747680315726078002853876058955863276687817154045895351438246 > > 423432132688946418276846754670353751698604991057655128207624 > > 549009038932894407586850845513394230458323690322294816580855 > > 933212334827479782620414472316873817718091929988125040402618 > > 4124858368 > >=20 > > Yours sincerely Margaret Gr=FCnKerr > >=20 > >=20 > >=20 > >=20 > >=20 > >  > > This SF.net email is sponsored by: VM Ware > > With VMware you can run multiple operating systems on a > > single machine. WITHOUT REBOOTING! Mix Linux / Windows /=20 > > Novell virtual machines at the same time. Free trial click=20 > > here: http://www.vmware.com/wl/offer/345/0 > > _______________________________________________ > > saxonhelp mailing list > > saxonhelp@...=20 > > https://lists.sourceforge.net/lists/listinfo/s>; axonhelp > >=20 >=20 >=20 >=20 >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a=20 > single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual=20 > machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > saxonhelp mailing list > saxonhelp@... > https://lists.sourceforge.net/lists/listinfo/saxonhelp >=20 
From: <margaret.gruenkerr@di...>  20030721 10:45:10

I wasn't sure what to expect, that is why I tried it in the first place, I had 2 alternatives: Alternative 1 17976931348623157000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000 0000000000.0 XPath1 sect. 4.2 otherwise, the number is represented in decimal form as a Number including a decimal point with at least one digit before the decimal point and at least one digit after the decimal point, preceded by a minus sign () if the number is negative; there must be no leading zeros before the decimal point apart possibly from the one required digit immediately before the decimal point; beyond the one required digit after the decimal point there must be as many, but only as many, more digits as are needed to uniquely distinguish the number from all other IEEE 754 numeric values or Alternative 2: 1.7976931348623157E308 XQuery 1.0 and XPath 2.0 Functions and Operators section 17.7 XmlSchema 2 3.2.5.2 double values have a lexical representation consisting of a mantissa followed, optionally, by the character "E" or "e", followed by an exponent. The exponent ·must· be an integer. The mantissa must be a decimal number. The representations for exponent and mantissa must follow the lexical rules for integer and decimal. If the "E" or "e" and the following exponent are omitted, an exponent value of 0 is assumed. Margaret Grün > Just to add to my earlier response, note the XML Schema definition of > the xs:double data type: > > The basic ·value space· of double consists of the values m × 2^e, where > m is an integer whose absolute value is less than 2^53, and e is an > integer between 1075 and 970, inclusive. > > It goes on to say that the string "1.7976931348623157E308" should be > represented as the closest possible number in this value space. > > In the case of an exponent such as E308, this number is going to be a > large integer, and it is very unlikely that this integer, when output in > decimal notation, will end in lots of zeros, which seems to be what you > are expecting. In fact, the definition above tells you that the largest > negative double is (2^53  1) x 2^970. > > Michael Kay > >> Original Message >> From: saxonhelpadmin@... >> [mailto:saxonhelpadmin@...] On Behalf Of >> Michael Kay >> Sent: 18 July 2003 19:35 >> To: 'Margaret GrünKerr'; saxonhelp@... >> Subject: RE: [saxon] xs:double("1.7976931348623157E308") >> >> >> What precision did you expect, and why? >> >> Note that Saxon is currently following the XPath 1.0 rules in >> this area. The XPath 2.0 rules for converting doubles to >> strings are still in flux. XPath 1.0 is very precise about >> the expected result, and I believe Saxon is doing the correct >> thing, though I don't have time to prove it to you just now, >> as I'm about to disappear on vacation. If you think it's >> wrong, please tell me what you think the right answer is, and why. >> >> Michael Kay >> >> > Original Message >> > From: saxonhelpadmin@... >> > [mailto:saxonhelpadmin@...] On Behalf Of >> > Margaret GrünKerr >> > Sent: 17 July 2003 09:34 >> > To: saxonhelp@... >> > Subject: [saxon] xs:double("1.7976931348623157E308") >> > >> > >> > I fished this example out of the NIST test suite. >> > The XSL file contained: >> > <xsl:text> >> > >> > "xs:double("1.7976931348623157E3 >> 08")" >> > </xsl:text> >> > >> > <xsl:valueof >> > select="xs:double("1.7976931348623157E308")"/> >> > >> > >> > The result had the requested order of magnitude (stringlenght >> > 310)but the precision was not as I expected: >> > >> > "xs:double("1.7976931348623157E308")" >> > >> > 17976931348623157081452742373170435679807056752584499659891 >> 747680315726078002853876058955863276687817154045895351438246 >> 423432132688946418276846754670353751698604991057655128207624 >> 549009038932894407586850845513394230458323690322294816580855 >> 933212334827479782620414472316873817718091929988125040402618 >> 4124858368 >> > >> > Yours sincerely Margaret GrünKerr >> > >> > >> > >> > >> > >> >  >> > This SF.net email is sponsored by: VM Ware >> > With VMware you can run multiple operating systems on a >> > single machine. WITHOUT REBOOTING! Mix Linux / Windows / >> > Novell virtual machines at the same time. Free trial click >> > here: http://www.vmware.com/wl/offer/345/0 >> > _______________________________________________ >> > saxonhelp mailing list >> > saxonhelp@... >> > https://lists.sourceforge.net/lists/listinfo/s>; axonhelp >> > >> >> >> >>  >> This SF.net email is sponsored by: VM Ware >> With VMware you can run multiple operating systems on a >> single machine. >> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual >> machines at the >> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 >> _______________________________________________ >> saxonhelp mailing list >> saxonhelp@... >> https://lists.sourceforge.net/lists/listinfo/saxonhelp >> 
From: Michael Kay <mhk@mh...>  20030804 08:00:27

Just to repeat my earier response: I believe that Saxon is doing the correct thing according to the XPath 1.0 specification, and I am waiting for the XPath 2.0 / XQuery 1.0 specification to stabilize in this area before I change the code. (I did actually implement the current 2.0 working draft, but I had to undo this change because the effects on backwards compatibility were disastrous. The WG is still debating what the spec should be.) Michael Kay > Original Message > From: saxonhelpadmin@...=20 > [mailto:saxonhelpadmin@...] On Behalf Of=20 > Margaret Gr=FCnKerr > Sent: 21 July 2003 11:45 > To: mhk@... > Cc: saxonhelp@... > Subject: RE: [saxon] xs:double('1.7976931348623157E308') >=20 >=20 > I wasn't sure what to expect, that is why I tried it in the=20 > first place, I had 2 alternatives: >=20 > Alternative 1=20 > 17976931348623157000000000000000000000000000000000000000000 > 000000000000000000000000000000000000000000000000000000000000 > 000000000000000000000000000000000000000000000000000000000000 > 000000000000000000000000000000000000000000000000000000000000 > 000000000000000000000000000000000000000000000000000000000000 > 0000000000.0 > XPath1 sect. 4.2 > otherwise, the number is represented in decimal form as a=20 > Number including a decimal point with at least one digit=20 > before the decimal point and at least one digit after the=20 > decimal point, preceded by a minus sign () if the number is=20 > negative; there must be no leading zeros before the decimal=20 > point apart possibly from the one required digit immediately=20 > before the decimal point; beyond the one required digit after=20 > the decimal point there must be as many, but only as many,=20 > more digits as are needed to uniquely distinguish the number=20 > from all other IEEE 754 numeric values >=20 > or > Alternative 2: 1.7976931348623157E308 > XQuery 1.0 and XPath 2.0 Functions and Operators section 17.7=20 > XmlSchema 2 3.2.5.2 double values have a lexical=20 > representation consisting of a mantissa followed, optionally,=20 > by the character "E" or "e", followed by an exponent. The=20 > exponent =B7must=B7 be an integer. The mantissa must be a decimal=20 > number. The representations for exponent and mantissa must=20 > follow the lexical rules for integer and decimal. If the "E"=20 > or "e" and the following exponent are omitted, an exponent=20 > value of 0 is assumed. >=20 > Margaret Gr=FCn >=20 > > Just to add to my earlier response, note the XML Schema=20 > definition of=20 > > the xs:double data type: > > > > The basic =B7value space=B7 of double consists of the values m =D7 = 2^e,=20 > > where m is an integer whose absolute value is less than=20 > 2^53, and e is=20 > > an integer between 1075 and 970, inclusive. > > > > It goes on to say that the string "1.7976931348623157E308"=20 > should be=20 > > represented as the closest possible number in this value space. > > > > In the case of an exponent such as E308, this number is=20 > going to be a=20 > > large integer, and it is very unlikely that this integer,=20 > when output=20 > > in decimal notation, will end in lots of zeros, which seems=20 > to be what=20 > > you are expecting. In fact, the definition above tells you that the=20 > > largest negative double is (2^53  1) x 2^970. > > > > Michael Kay > > > >> Original Message > >> From: saxonhelpadmin@... > >> [mailto:saxonhelpadmin@...] On Behalf=20 > Of Michael=20 > >> Kay > >> Sent: 18 July 2003 19:35 > >> To: 'Margaret Gr=FCnKerr'; saxonhelp@... > >> Subject: RE: [saxon] xs:double("1.7976931348623157E308") > >> > >> > >> What precision did you expect, and why? > >> > >> Note that Saxon is currently following the XPath 1.0 rules in this=20 > >> area. The XPath 2.0 rules for converting doubles to=20 > strings are still=20 > >> in flux. XPath 1.0 is very precise about the expected=20 > result, and I=20 > >> believe Saxon is doing the correct thing, though I don't=20 > have time to=20 > >> prove it to you just now, as I'm about to disappear on=20 > vacation. If=20 > >> you think it's wrong, please tell me what you think the=20 > right answer=20 > >> is, and why. > >> > >> Michael Kay > >> > >> > Original Message > >> > From: saxonhelpadmin@... > >> > [mailto:saxonhelpadmin@...] On Behalf Of=20 > >> > Margaret Gr=FCnKerr > >> > Sent: 17 July 2003 09:34 > >> > To: saxonhelp@... > >> > Subject: [saxon] xs:double("1.7976931348623157E308") > >> > > >> > > >> > I fished this example out of the NIST test suite. > >> > The XSL file contained: > >> > <xsl:text> > >> > > >> > "xs:double("1.7976931348623157E3 > >> 08")" > >> > </xsl:text> > >> > > >> > <xsl:valueof=20 > >> > select=3D"xs:double("1.7976931348623157E308")"/> > >> > > >> > > >> > The result had the requested order of magnitude (stringlenght=20 > >> > 310)but the precision was not as I expected: > >> > > >> > =20 > "xs:double("1.7976931348623157E308")" > >> > > >> > 17976931348623157081452742373170435679807056752584499659891 > >> 747680315726078002853876058955863276687817154045895351438246 > >> 423432132688946418276846754670353751698604991057655128207624 > >> 549009038932894407586850845513394230458323690322294816580855 > >> 933212334827479782620414472316873817718091929988125040402618 > >> 4124858368 > >> > > >> > Yours sincerely Margaret Gr=FCnKerr > >> > > >> > > >> > > >> > > >> > > >> >  > >> > This SF.net email is sponsored by: VM Ware > >> > With VMware you can run multiple operating systems on a single=20 > >> > machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual=20 > >> > machines at the same time. Free trial click > >> > here: http://www.vmware.com/wl/offer/345/0 > >> > _______________________________________________ > >> > saxonhelp mailing list > >> > saxonhelp@...=20 > >> > https://lists.sourceforge.net/lists/listinfo/s>; axonhelp > >> > > >> > >> > >> > >>  > >> This SF.net email is sponsored by: VM Ware > >> With VMware you can run multiple operating systems on a single=20 > >> machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > >> machines at the > >> same time. Free trial click here:=20 > http://www.vmware.com/wl/offer/345/0 > >>=20 > _______________________________________________ > >> saxonhelp mailing list > >> saxonhelp@... > >> https://lists.sourceforge.net/lists/listinfo/saxonhelp > >> >=20 >=20 >=20 >=20 >=20 >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a=20 > single machine. WITHOUT REBOOTING! Mix Linux / Windows /=20 > Novell virtual machines at the same time. Free trial click=20 > here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > saxonhelp mailing list > saxonhelp@...=20 > https://lists.sourceforge.net/lists/listinfo/s>; axonhelp >=20 