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 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?

>
> *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 )

>   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.
>

Received on Tuesday, 2 August 2005 20:01:29 UTC