Update on Comparision Functions (equality, sameness, etc.)

The next build will modify the comparison functions and operators for all datatypes according to our earlier discussion (See Numeric almost-equal, equal, strict-equal, and... ? below).

This is a major change, but should not affect most code. However, it does promote all comparison actions to natives. That really shouldn't change anything, but it's worth noting.

For validation, Ladislav has created a first pass at test files to verify the desired operation. The defining document is Comparisions as published in the DocBase wiki, and there are links to various test files. The official test files are stored in R3 Chat #23 -- just type "get *" to download them.

Ok... although comparison is now more consistent, there are still a few rough spots that need to be worked out. Let me list a few, and I'm sure there will be more:

The new definition made equality valid for similar (but not identical datatypes.) For example, "test" = <test>, but "test" == <test> remains false. This could be problematic because it really stretches the definition of equality. One solution would be to make EQUIV? weaker than EQUAL?, and allow EQUIV? "test" <test> to be true, but EQUAL? to be false. Let's talk about it.
In A3 there is no equality relationship between binary and string. A binary requires decoding before it can be compared with a string. Such decoding is beyond the scope of the comparison functions.
Comparison between binary and numeric datatypes should not be assumed. Again, this is an encoding issue. Use a TO conversion first.
In a prior release, I modified date equality (EQUAL? level) to also include time. But, we've long debated this issue, and perhaps it should remain as it was. (E.g. Jan 10th is Jan 10th, regardless of what time it is.)
ZERO? needs better definition. In my code, I use it quite often as a test of equality to zero. The deeper question is: what datatypes should it include? This trivial question does not have a trivial answer.

14 Comments