- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Sat, 22 Oct 2005 20:34:31 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: Eric Prud'hommeaux <eric@w3.org>, public-rdf-dawg@w3.org
Seaborne, Andy wrote: . . . > Other 3: > > This is an observation and unrelated to the new format. I found in 11.1.1 > > """ > XML Schema defines a set of types derived from decimal: integer; > nonPositiveInteger; negativeInteger; long; int; short; byte; > nonNegativeInteger; unsignedLong; unsignedInt; unsignedShort; > unsignedByte and positiveInteger. These are all treated as decimals for > arithmetic operations in FILTERs. SPARQL does not specifically require > integrity checks on derived subtypes. > """ > > I agree it does not lead to an observable difference (because we have > only one version of divide) but the language is different in F&O where > it says "integer + integer => integer", not decimal. > > Second table - > http://www.w3.org/TR/xpath-functions/#op.numeric > > If a custom function were to provide idiv, op:numeric-integer-divide, > then the difference would observable because the types of input affect > the value out. > > Hmm - that is at odds with the principle that SPARQL operates on values. > 1/2 should not depend on whether it's "1"^^xsd:integer or > "1"^^xsd:double (in the presence of D-entailment at least). I was wrong - the definition of op:numeric-integer-divide doesn't lead to this situation. Andy > > Andy >
Received on Saturday, 22 October 2005 19:34:52 UTC