Re: The naive test for equality

David Cressey wrote:
> "Paul" <paul_at_test.com> wrote in message
> news:42f50fc1$0$24006$ed2619ec_at_ptn-nntp-reader01.plus.net...
> > Marshall Spight wrote:
> > >>I've kind of lost track of what started this thread in the first place
> > >>now! I think it was just to say I didn't think there was any real
> > >>difference between equality and equivalence relations. Each one defines
> > >>the other.
> > >
>
> OK, let me jump in with what I think I was about with this thread in the
> first place.
>
> A lot of other discussion hinges about the interaction between the
> relational engine and the type engine.
>
> I think there are multiple layers of representation/interpretation in any
> system of representing meaning using symbols.
>
> For certain equalities of the underlying things ("values" for some people),
> it's the type engine that knows when two tokens are representations for the
> same underlying thing. Thus, if we want to know whether 1/2 s really equal
> to 2/4 or not, we consult the appropriate tpye engine, in this case the
> rational type engine. If we want to know whether 123.45E1 is really equal
> to 12.345E2 we consult the floating point number type engine.
>
> As far as I'm concerned "consulting the type engine" is another way of
> saying what VC said when he said we must put the items in context before we
> can test them for equality.
>
> With regard to whether A is equal to B or not, we need to consult three
> engines:
>
> First the variable typing engine to see if A and B are or are not of the
> same type. If we have static typing of variables, we can do this test at
> compile time.
>
> Next, the variable state remembering engine to retrieve the current (in
> context) value of A and B.
>
> Next the type engine determined by the common type of A and B to find out
> whether the values are really the same or not.
>
> If we omit the last step, we will end up doing a naive test for equality.
> If there are any synonyms that the type engine knows about and we don't know
> about, then our test for equality will be naive.
>
>
> Here's where I'm going with this: in an SQL DBMS, where is the type engine
> for the type "SQL Table". Or isn't there one?
>
I don't know the answer to this question directly, but I've been thinking about what I understood to be your question and have a couple of comments that might or might not be relevant.

If you are equality between relations (not just header), you are including equality related to words and their referents, not only mathematical expressions. [I'm usng the term "referents" here as used in semiotics rather than grammer or programming languages.] We have the concept of equality defined in mathematics, but we do not have the same in a language like English. Even with the concept of synonyms, we are not talking "equals".

If we were to stretch the meaning so that if two word values are close enough in meaning we call them equal, we would end up with some of the same issues that arise when attempting to model the entire language with mathematics. Too much interpretation, context, pragmatics (if I'm using that term correctly, again from semiotics) lies outside of what we capture or even can capture in the metadata. We would get into the "Time flies like an arrow" problems. Is that equal to "Time flies enjoy an arrow"?

We would also need to be able to determine if 'Jo Doe' was the same person as 'Jo Doe Jr' but the data entry person in the one case did not enter Jr as a suffix. Or that Pat DeJong in one table is the same person as Pat DeJong in another. They could even both have the same unique id (candidate key) value, doled out by two different systems for two different people, but the representation (string value) for each is the same. How would you have enough information to be certain these were the same people? You would need to have a unique identifier not just for a table, but for the entire human race (under some conditions you could require the exact same ssn, for example) and the system would have to know that. Think of the various algorithms that attempt to match two names as being the same in order to help de-dup data. They only provide assistance, nothing close to exact.

And then there is the fact that you and I both speak English, but have missed with each other more than once. Two people often cannot agree on what words are equal.

In case I'm not understanding your question (am I in the ballpark?), this response might be completely irrelevant in which case, nevermind.

cheers! --dawn Received on Sun Aug 07 2005 - 05:54:49 CEST