Re: [OK?] Bug: "A value disjunction that encounters a type error on only one branch will return the result of evaluating the other branch."

On Tue, Aug 02, 2005 at 04:01:25PM -0400, Tim Berners-Lee wrote:
> 
> On Aug 2, 2005, at 12:47, Eric Prud'hommeaux wrote:
> 
> >On Tue, Aug 02, 2005 at 11:27:24AM -0400, Tim Berners-Lee wrote:
> >
> >>
> >>The current last call draft states,
> >>
> >>"A value disjunction that encounters a type error on only one branch
> >>will return the result of evaluating the other branch."
> >>
> >>This seems to be a bug: inconsistent with the logic one would expect.
> >> It is inconsistent with the general rule that the disjunction of
> >>false with x is x for all x. The disjunction of false with a type
> >>error is therefore a type error.  If not, the type error is masked.
> >>
> >>Example in english:  An alarm should fire if either ?smokeDetected or
> >>the ?temperature is above 40.  Suppose the ?smokeDetected is false
> 
> 
> False, note.
> 
> >>and the temperature is (because of a bug) bound to something which
> >>can't be compared to 40 without a type error.  The result should be
> >>that the alarm is a type error.  Instead, with the wording above, the
> >>alarm is suppressed.
> >>
> >
> >I tried making this concrete, but found it supporting the spec's
> >current wording.
> >
> >DATA:
> >
> >@prefix : <asdf> .
> >:detector :temp \"314\"^^:degreesK ;
> >          :smokeDetects 1 .
> 
> Should that be 0?

There is no way to report typeErrors encountered when testing the
bindings in a particular solution. This is typical of query langs
like XPath (as used in either in XQuery or XSLT) and SQL. The
distinction between a "type error" and "suppressed", identified
above, is unobservable.

I answered a slightly different question to demonstrate where the
type error would have an observable effect.

> >*note* degreesK is not known by this SPARQL engine and therefor is not
> >known to be numeric and therefor throws a type error at the >  
> >operator.
> >
> >QUERY:
> >
> >PREFIX : <asdf>
> >SELECT ?smokeDetected ?temperature
> > WHERE { :detector :smokeDetects ?smokeDetected .
> >       :detector :temp ?temperature .
> >       FILTER (?temperature > 40 || ?smokeDetected) }
> >
> >RESULTS:
> >  under current semantics:
> >[] fire:eek [] .
> >
> 
> 
> I suspect with no smoke detected the result would be no  results,  
> when in fact the temperature is too high.   Please try it with 505K  
> to make the point! :-)
> 
> (505K =  273+((451-32)*5/9)K )

    unagi:/home/eric$ units
2084 units, 71 prefixes, 32 nonlinear units

You have: 40 degrees C
You want: degrees Kelvin
Unknown unit 'Kelvin'
You want: degrees K
conformability error
        0.6981317 A radian s
        0.017453293 K radian

stupid units program

I was assuming that you meant degrees C; 273.15+40 < 314 .


> >  if the type error passes through the disjunction there are no  
> >results.
> >
> >Does this clarify the effect of || masking type errors?
> >Is this effect now acceptable?
> >Would you like clarifying wording in the spec?
> >
> >
> >>Yosi Scharf found also that this rule for union means that de
> >>Morgan's laws don't hold properly, making the  compilation and
> >>optimization of queries more difficult or impossible.
> >>
> >>Tim Berners-Lee
> >>MIT/CSAIL/DIG
> >>
> >

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.