Easy as { 1 2 3 }? (when { 1 2 3 } ≠ { 1 2 3 })

[DavidM]

While testing some RPL code recently, I was reminded of a problem that can occur on the 50g when attempting to test lists for equality. Here's an example of how the problem can show up:

1) Set your 50g to exact mode
2) Enter the list { 1 2 3 } on the stack
3) Press ENTER to make a duplicate, then 2 * to double each list element
4) Press 2 / to divide each element in the second list by 2

At this point, you should have what appears to be two identical lists in stack levels 1 and 2:
2: { 1 2 3 }
1: { 1 2 3 }

Execute SAME (or ==) to compare the two lists for equality. I'm of the opinion that most rational people would expect a result of 1, but unfortunately my rev 2.15 50g sees those lists as not being the same. The reason for this is a bit complicated, and even worse, it's not as predictable as you might imagine. Try the same test as above, but this time use { 10 20 30 } as the initial list. Surprise! Unlike before, those lists are the same. Likewise, try multiplying or dividing by 1 instead of 2. What result do you think that will give?

What's the difference, and why does this happen? The answer to that is a bit complicated, and has to do with the following:

1. How the built-in RPL compiler substitutes whole numbers in the range -9..9 with a reference to a ROM-based constant instead of a raw value when it is invoked
2. How SAME/== only looks at the binary data of the whole list (instead of individual elements) when comparing for equality
3. How mathematical operations involving exact integers sometimes result in raw values, and sometimes don't
   

The 50g is far more consistent with its handling of approximate numbers, so this isn't usually a problem with those values. I've yet to find a way to cause a similar problem with approximate numbers.

I'm curious as to whether others have run into this issue, and if so, how you dealt with it. The only UserRPL methods I can think of are very slow as list sizes increase (eg. applying →STR STR→ to the lists before comparing). What methods have you found to deal with this?

Note that this is really just an issue for the 48gII/49g+/50g, as earlier RPL models either don't use exact integers or treat them differently when performing math operations on lists of them. On my rev. 1.19-6 49G, { 1 2 3 } 2 * strangely yields a result of { 2. 4. 6. }, regardless of mode.