[Bug 28795] [F+O] 3.1 Non-transitive equality for numerics in maps

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28795

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
Bug #28632 originally concerned timezones in maps, but it morphed into a
discussion about handling numerics where the "eq" operator is non-transitive as
a result of numeric promotion. I want to push back on the decision in that
area.

Any off-the-shelf implementation of maps is going to assume transitive
equality. Handling the semantics we decided upon, where remove() can remove two
entries that are both equal to the supplied key but not equal to each other,
requires considerable complexity, and straying from the algorithms and data
structure text books. This is complex, expensive, and error prone, and I don't
think it is justified by any usability benefit.

There is an alternative, which is to define key matching so that two numeric
values are equal only if they are mathematically equal, with no rounding or
approximation. Our problems with transitivity arise because "promotion" from
decimal to double involves rounding. For the definition of "same key" we should
say that two numerics of different type compare equal only if they are exactly
equal. Note that every float and double is exactly equal to some decimal if you
have enough digits of precision available, so in effect this means reversing
the order of promotion to float->double->decimal and using an implementation of
decimal with enough digits so conversion from a double is lossless.

Is the problem for maps worse than the existing problem for distinct-values and
for grouping? Those cases too are likely to be supported by some off-the-shelf
map implementation. In my case the additional challenge is partly because an
efficient implementation of maps where updates don't destroy the original is
already a lot more complex than an implementation with in-situ update, which is
all you need for distinct-values and grouping. Those functions also don't need
a remove() operation.

(If we define a new equality relation then we could also consider using it, of
course, for distinct-values() and grouping. I'm not proposing that at the
moment - it has compatibility implications, though I find it impossible to
believe anyone is actually relying on the current non-transitive behaviour.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 11 June 2015 15:54:34 UTC