1312388 - Collator Compare decimals

Status: RESOLVED INVALID

(Core :: JavaScript: Internationalization API, defect)

Description

[nsd]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce:

The following JavaScript snippet can be executed in the console:
console.log(new Intl.Collator(undefined, { numeric: true}).compare(0.000005, 0.05))

It can also be executed from the following stackoverflow question: http://stackoverflow.com/q/40107588


Actual results:

The compare functions seems to think that both numbers are the same.


Expected results:

The numbers are different and therefor the function should have returned an non-zero number.

Internet Explorer & Edge returns -1 where as Google Chrome has the same issue as Firefox.

Comment 1

[Loic]

Rounding issue?

Comment 2

[Jeff Walden [:Waldo]]

Not a rounding issue, for sure (at least not in SpiderMonkey itself).  Both numbers are converted to strings before anything happens, and they do stringify to what they look like.

I'm stepping through this in a debugger, and it's turned into a morass of ICU code doing stuff with sensitivities and other things I'm not particularly familiar with.  Bah.  Not sure how far I'll get with this tack, exactly, but I'll give it a little more time.

Comment 3

[André Bargull [:anba]]

Firefox, Chrome and Safari are all using the ICU library to implement the Intl.Collator object. ICU itself follows the Unicode Technical Standard #35 [1] for the numeric ordering collation option. And per UTS#35, numeric ordering sorts numbers according to their 'numeric value', starting at the 'digit reordering group'. AFAICT the dot "." seems to start a new digit reordering group, so in the test case from above, we're effectively comparing "000005" against "05". Both strings have the numeric value and are therefore compared as equal. A similar case is `Intl.Collator(undefined, {numeric: true}).compare("05", "5")`. Firefox, Chrome and Safari return 0, whereas Edge/IE returns -1. 

[1] http://unicode.org/reports/tr35/tr35-collation.html#Setting_Options , entry for numericOrdering

Comment 4

[Jeff Walden [:Waldo]]

(In reply to André Bargull from comment #3)
> ICU itself follows the Unicode Technical Standard #35
> [1] for the numeric ordering collation option. And per UTS#35, numeric
> ordering sorts numbers according to their 'numeric value', starting at the
> 'digit reordering group'. AFAICT the dot "." seems to start a new digit
> reordering group, so in the test case from above, we're effectively
> comparing "000005" against "05".

(hello Dunning-Kruger)  I'm not sure we even need to go that far (or at least we don't need to go into the funky terminology).  The UTS#35 wording is "any sequence of Decimal Digits (General_Category = Nd in the [UAX44]) is sorted at a primary level with its numeric value".  U+002E FULL STOP is in General_Category = Po, not Nd.  So "0" = "0" means 0 = 0 and so they compare equal, "." = "." just by codepoint comparison, and "000005" = "05" means 5 = 5 and so they compare equal.  Thus in the end both strings compare equal.

Given that, this seems INVALID, and it's IE/Edge who are in the wrong here.