From: <gu...@ga...> - 2005-01-31 07:31:40
|
Hi all, I stored the following xml in eXist : <?xml version="1.0" encoding="UTF-8"?> <tests> <test>123?</test> <test>12</test> <test>123a</test> <test>456</test> </tests> And then I did the following simple query: //test[string(number(./text())) != "NaN"] This always returns the following error : Error found: cannot convert string '123?' into a double. Normally, following XPath specs, it should return all nodes containing a legitimate number. Someone could explain what is wrong ? Thanks Guy |
From: Wolfgang M. <wol...@ex...> - 2005-01-31 21:53:39
Attachments:
number.patch
|
> Hi all, > > I stored the following xml in eXist : > > <?xml version="1.0" encoding="UTF-8"?> > <tests> > <test>123?</test> > <test>12</test> > <test>123a</test> > <test>456</test> > </tests> > > And then I did the following simple query: > > //test[string(number(./text())) != "NaN"] > > This always returns the following error : > > * Error found: cannot convert string '123?' into a double. > * > Normally, following XPath specs, it should return all nodes > containing a legitimate number. You are right. number() should return NaN and not throw an exception. I attach a patch to fix this issue. Wolfgang |
From: <gu...@ga...> - 2005-02-01 07:14:38
|
Hi Wolfgang, Thank you very much Guy Le 31 janv. 05, =E0 22:53, Wolfgang Meier a =E9crit : >> Hi all, >> I stored the following xml in eXist : >> <?xml version=3D"1.0" encoding=3D"UTF-8"?> >> <tests> >> <test>123?</test> >> <test>12</test> >> <test>123a</test> >> <test>456</test> >> </tests> >> And then I did the following simple query: >> //test[string(number(./text())) !=3D "NaN"] >> This always returns the following error : >> * Error found: cannot convert string '123?' into a double. >> * >> Normally, following XPath specs, it should return all nodes >> containing a legitimate number. > > You are right. number() should return NaN and not throw an exception. =20= > I attach a patch to fix this issue. > > Wolfgang > > Index: FunNumber.java > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: =20 > /cvsroot/exist/eXist-1.0/src/org/exist/xquery/functions/=20 > FunNumber.java,v > retrieving revision 1.4 > diff -u -r1.4 FunNumber.java > --- FunNumber.java 14 Nov 2004 22:15:12 -0000 1.4 > +++ FunNumber.java 31 Jan 2005 21:48:39 -0000 > @@ -70,7 +70,12 @@ > arg =3D contextSequence; > if(arg.getLength() =3D=3D 0) > return DoubleValue.NaN; > - else > - return arg.convertTo(Type.DOUBLE); > + else { > + try { > + return arg.convertTo(Type.DOUBLE); > + } catch(XPathException e) { > + return DoubleValue.NaN; > + } > + } > } > } |
From: Pierrick B. <pie...@cu...> - 2005-02-01 08:17:34
|
Hi, Wolfgang Meier a =E9crit : >> And then I did the following simple query: >> >> //test[string(number(./text())) !=3D "NaN"] >> >> This always returns the following error : >> >> * Error found: cannot convert string '123?' into a double. >> * >> Normally, following XPath specs, it should return all nodes >> containing a legitimate number. >=20 >=20 > You are right. number() should return NaN and not throw an exception. I= =20 > attach a patch to fix this issue. > Index: FunNumber.java > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /cvsroot/exist/eXist-1.0/src/org/exist/xquery/functions/FunNu= mber.java,v > retrieving revision 1.4 > diff -u -r1.4 FunNumber.java > --- FunNumber.java 14 Nov 2004 22:15:12 -0000 1.4 > +++ FunNumber.java 31 Jan 2005 21:48:39 -0000 > @@ -70,7 +70,12 @@ Is that enough ? Shouldn't org.exist.xquery.value.NumericValue be=20 patched as well ? Well, inherited classes should also be patched, maybe after making=20 abstract code concrete in order to get benefit from the super class or=20 after creating a dedicated helper class. For example, in org.exist.xquery.value.DoubleValue : public DoubleValue(String stringValue) throws XPathException { ... should handle specific cases ("NaN", "+INF", "-INF"...), possibly=20 from the super class, before trying to set the actual value, i.e. : value =3D Double.parseDouble(stringValue); The like for : public String getStringValue() { ... and numeric operations on specific values, as stated by=20 http://www.w3.org/TR/2001/WD-xquery-operators-20011220/#op.numeric. Is my analysis wrong ? Cheers, --=20 Pierrick Brihaye, informaticien Service r=E9gional de l'Inventaire DRAC Bretagne mailto:pie...@cu... +33 (0)2 99 29 67 78 |
From: Wolfgang M. <wol...@ex...> - 2005-02-01 11:20:57
|
Hi, > Is that enough ? Shouldn't org.exist.xquery.value.NumericValue be > patched as well ? > > Well, inherited classes should also be patched, maybe after making > abstract code concrete in order to get benefit from the super class or > after creating a dedicated helper class. > > For example, in org.exist.xquery.value.DoubleValue : > > public DoubleValue(String stringValue) throws XPathException { > > ... should handle specific cases ("NaN", "+INF", "-INF"...), possibly > from the super class, before trying to set the actual value, i.e. : > > value = Double.parseDouble(stringValue); Yes, that's correct. Double.parseDouble handles "NaN", but not "+INF" etc. I don't know how BigDecimal behaves. > The like for : > > public String getStringValue() { DoubleValue.getStringValue() should be correct, but I'm not sure for DecimalValue... We probably need to test all those cases. Wolfgang |
From: Pierrick B. <pie...@cu...> - 2005-02-01 13:59:58
|
Hi again, Wolfgang Meier a =E9crit : >> ... should handle specific cases ("NaN", "+INF", "-INF"...), possibly=20 >> from the super class, before trying to set the actual value, i.e. : >> >> value =3D Double.parseDouble(stringValue); >=20 >=20 > Yes, that's correct. Double.parseDouble handles "NaN", but not "+INF"=20 > etc. I don't know how BigDecimal behaves. Following=20 http://www.w3.org/TR/2001/WD-xquery-operators-20011220/#op.numeric : > For float and double, the string argument can indicate the special valu= es: NaN, INF, -INF, +0, and -0. This infers that every other type should raise an exception. Am I wrong ? >> The like for : >> >> public String getStringValue() { >=20 > DoubleValue.getStringValue() should be correct Mmmh... if (!Double.isInfinite(value) && (value >=3D (double) (1L << 53) || -value >=3D (double) (1L << 53)))= { return new java.math.BigDecimal(value).toString(); } String s =3D Double.toString(value); ... try to deal with a real (mathematic sense of the word) value... This should be OK for INF values (not sure however)... but what about=20 "NaN" ? Well, it looks like public boolean isNaN() isn't used anywhere,=20 but, please, return early ! > but I'm not sure for=20 > DecimalValue... Well, regarding the specs, DecimalValue isn't concerned. I'd really like to help you in commiting patches, but unfortunately I am=20 behin a fascist firewall :-( Furthermore, for these XPath cases, shouldn't eXist offer some test=20 cases ? NIST XQuery test suite=20 (http://xw2k.sdct.itl.nist.gov/BRADY/xmlquery/testSuite/NIST/files/readme= .html)=20 seems to be OK (although there are no preset results available because=20 of an over_humility problem :-), a nice potential contribution from=20 eXist users ?!). Cheers, --=20 Pierrick Brihaye, informaticien Service r=E9gional de l'Inventaire DRAC Bretagne mailto:pie...@cu... +33 (0)2 99 29 67 78 |