Well that was an interesting way to waste an hour or two. Puzzle solved -
but I'm still not sure if it's a bug or a feature.
Recap: The problem was that my code, which often compares pairs of ten
character strings, had hit a case where two apparently (and in fact
actually) identical ten character strings were failing the equality test.
The strings are hex digits. The problem arises if and only if all but one
characters, including the first, and the last three, are decimal digits, and
the remaining character is the hex digit "E". So for example,
put "9E707" = "9E707" --> false
Obviously what's happening here is the that the two strings are capable of
being interpreted as numbers in scientific notation; and in that
interpretation they are very large numbers; and I guess that Rev/MC is
taking the approach that anything which can be treated as a number should
be; and further, that when comparing two extremely large numbers, it can't
be sure if they're the same number.... so it returns false.
Each step in that seems like a feature - but the result seems like a bug.
Obviously I can now modify my code to add a letter to each string before
comparing, to force them to be compared as strings, to avoid this situation
arising again. But I do think that Rev/MC shouldn't be so eager to force
the conversion to numbers. It also leads to the opposite problem, for
example:
put "+0" = "-0" --> true
Of course they may be equal as numbers; but I would have expected to have to
force the numeric interpretation to get this result, eg by adding zero to
each item.
Bug or feature?
Ben Rubinstein | Email: [EMAIL PROTECTED]
Cognitive Applications Ltd | Phone: +44 (0)1273-821600
http://www.cogapp.com | Fax : +44 (0)1273-728866
_______________________________________________
improve-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/improve-revolution
