Re: The naive test for equality

David Cressey wrote:
> Now, whenever we are given an unnormalized rational, such as 5/10,
we ask
> the rationals engine to normalize it for us.
> The rationals engine knows the rule for normalizing, namely remove common
> factors in the numerator and denominator. So it returns 1/2, the
> normalized equivalent of 5/10.
>
> If we ask the rationals engine to normalize 1/2, it will give us back 1/2.
>
> So the process of normalizing is choosing one, out of an equivalence class,
> according to some criterion, and using the symbol that represents the
> chosen element to act as the normalized form for the entire class.

What behaviour we want for types with multiple representations per value though? (I'm using words like "representation" in their common spoken usage here!)

If I store the value 2/4 in a database, then I retrieve it later, do I want it to remember the representation as well as the value? i.e. should it return 2/4 or 1/2?

If we always convert to a canonical form before storing then the DBMS can do equality comparisons at the physical bit level without recourse to the type details.

Another alternative might be for it to be internally stored both as the inserted form (2/4) and the canonical form (1/2). Not very good for disk space usage but if this isn't an issue...

An important part of defining a type might be to make sure the optimizer knows whether there is a 1-1 mapping between values and representatives or not. If there is, it makes equality comparisons easier.

Some databases can compare strings for equality in a case-insensitive way. (MSSQL has this option for example.) When you store a string, it remembers the case of each letter. But when you test two strings for equality, it ignores case. So here's a common example of a type where it is 1-many between values and representations.

Paul. Received on Tue Aug 09 2005 - 23:28:03 CEST