Re: set-valued values

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 08 Dec 2006 01:12:23 GMT
Message-ID: <XZ2eh.29985$cz.450303_at_ursa-nb00s0.nbnet.nb.ca>


paul c wrote:

> Bob Badour wrote:
> 

>> paul c wrote:
>>
>>> Another maybe crazy question - if instead of 'atomic values'
>>> (whatever that means) a relational engine (note for David, I've
>>> avoided using the term 'DBMS' !) expressed only values made up of
>>> sets, would the presence of the empty set in both true and false
>>> extensions create any problems? (I'm thinking that the relational
>>> requirement of attribute names means there is no problem, eg., the
>>> presence of empty sets is just an artifact of the mechanism that can
>>> usually be safely ignored.)
>>>
>>> As for representation, sometimes such values can't be represented
>>> without access to other 'attributes', eg., values that are internal
>>> to an engine. My attitude (no reasoning involved I'm afraid to say)
>>> is that it's okay to give the builtin result 'true' in such cases.
>>> That way, the engine can proceed to manipulate the expression if
>>> further requests of made of it, concerning that result.
>>>
>>> p
>>
>>
>>
>> I don't see why the value would appear in both sets. An empty set is
>> different from a set containing the empty set as it's only element.
>>
>> {} != {{}}
> 
> 
> It's a conundrum for me.  On one hand, if the empty set is contained in 
> one extension, de Morgan tells us it is not in the other.  On the other 
> hand, its lack of an attribute seems to make it a member of both sets.
> 
> p

Huh? No, the set that it is not in is just empty.

{} != {{}}
^--not in that set

{} != {{}}

        ^--in this one Received on Fri Dec 08 2006 - 02:12:23 CET

Original text of this message