From: <bugzilla@jessica.w3.org>

Date: Thu, 11 Jun 2015 15:54:30 +0000

To: public-qt-comments@w3.org

Message-ID: <bug-28795-523-ym2Bu8TPew@http.www.w3.org/Bugs/Public/>

Date: Thu, 11 Jun 2015 15:54:30 +0000

To: public-qt-comments@w3.org

Message-ID: <bug-28795-523-ym2Bu8TPew@http.www.w3.org/Bugs/Public/>

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

*
This archive was generated by hypermail 2.3.1
: Thursday, 11 June 2015 15:54:34 UTC
*