Re: Dawn doesn't like 1NF

From: Laconic2 <laconic2_at_comcast.net>
Date: Sat, 16 Oct 2004 07:11:20 -0400
Message-ID: <8s6dnYcmsad6nOzcRVn-sw_at_comcast.com>


"Marshall Spight" <mspight_at_dnai.com> wrote in message news:hl0cd.188364$wV.92433_at_attbi_s54...
> "Laconic2" <laconic2_at_comcast.net> wrote in message
news:ye2dnRyBk-N2rO3cRVn-qQ_at_comcast.com...

> >
> > There's more here than meets the eye. Testing two of a UDT for
equality is
> > a whole lot more subtle than comparing the bits, bit by bit. I'm not
> > convinced that two values drawn from the same complex domain can be
easily
> > tested for equality.
>
> Any feelings people have that this problem is complicated is
> an artifact of the fact that all the systems we have *make* this problem
> complicated. But the problem itself is simple: you compare all the
> logical subelements, part by part, recursively, until you get to the
primitives,
> which you can compare directly.

I am not sure you got my point. In order to carry out the process you outlined, you have to know what the logical subelements ARE. For a UDT, only U knows what the logical sublements are. Prolog could compare the representations, bit by bit, but that's comparing the physical subelements, not the logical subelements.

>
>
> > Is {1, 2, 3} equal to {2, 3, 1} ?
>
> Yes.
>

And how to do go about figuring out that they are equal? And for two sets, each with a million elements, how do you carry out the procedure you outlined above, without sorting? And, if you do sort, how long will it take?

My above argument regarding UDT doesn't apply here, because we can expect the system to "know" sets. But testing two sets for equality is still non trivial.

>
> > Is 3.21E3 equal to 32.1E2 ?
>
> Is three thousand two hundred and ten equal to three thousand two
> hundred and ten? Certainly.
>

OK, but how about if these two have different internal representations in binary? (different exponent, different mantissa, same value). This is really the synonym problem, in a different guise.

 I never worked with IEEE floating numbers. I worked with floating point arithmetic with three processors: DEC PDP-6, DEC PDP-10, and IBM 7090. In all of them, there was a process the the floating point arithmetic went through after calculating the answer. It was called "normalizing" (coincidence, or not?). It would adjust the exponent and mantissa until the mantissa was in a certain range or something.

> There are only two areas of complexity in equality: identity and
> precision. Identity disappears completely if you don't allow pointers
> in the language. Precision is harder: is the rational number 1/3 equal
> to the IEEE-754 double precision floating point value 1.0d/3.0d?
> Sadly no, but this is a simple consequence of having finite precision
> floating point numbers. Rationals have no such trouble, but floats
> are implemented in hardware, so we typically must bow down
> before their awesome performance.
>

OK, I should have said earlier that I was NOT dealing with the "approximately equal to" question.

BTW, it's not that floats are implemented in hardware that causes the problem: it's that floats are implemented in a finite state machine, rather than a general Turing machine. You would have the same problem with software floats, although you could obviate it in a significant subset of cases. Received on Sat Oct 16 2004 - 13:11:20 CEST

Original text of this message