TC39 General
2025-04-07
plaintext logs
prev next
source on github
02:28
<littledan>
yes, this would definitely be good to do, IMO
06:08
<Aapo Alasuutari>
I noticed a probably-known implementation inconsistency with Float64Array sorting regarding NaNs: According to spec, any call to Float64Array should canonicalise all NaNs in the TA's viewed buffer since it copies data from the buffer into a list of Values (canonicalising all NaNs here), performs sorting on that list and then writes the sorted items back into the buffer. On FF, a sort without a comparator seems to sort NaNs according to "absolute value" (uint64) while on Chrome they are left where they were. With a comparator (returning -1 or 1 randomly), on FF they NaNs become canonicalised while on Chrome they get sorted according to the comparator's wishes without canonicalisation. The spec seems fairly clear to me on this whole issue; canonicalisation happens on every sort call, but the lived reality is different. Should this be accepted, or is this something to file a bug to implementors about (if not already existent)? Or should this be a case where the spec is loosened to allow for implementation defined behaviour?
11:13
<Michael Ficarra>
@aapo.alasuutari:matrix.org: Seems like you should file issues against the implementations. Have you checked the JSC behaviour?
11:14
<Aapo Alasuutari>
Nope, I don't happen to have JSC at my fingertips quite the same as I have FF and Chrome.
11:20
<Aapo Alasuutari>

Okay, non-buggy test code:

b = BigUint64Array.of(9221120237041091055n, 9221120237041090774n);
console.log(b[0], b[1]);
a = new Float64Array(b.buffer);
a.sort();
console.log(b[0], b[1]);
a.sort(() => Math.random() ? -1 : 1);
console.log(b[0], b[1]);
11:25
<Aapo Alasuutari>
(I was wrong about FF ordering by "absolute value", that doesn't seem to happen. I must've accidentally sorted the BigUint64Array in one of my tests. Otherwise it all goes as I wrote.)
11:26
<nicolo-ribaudo>

in JSC it logs

9221120237041091055n 9221120237041090774n
9221120237041090560n 9221120237041090560n
9221120237041090560n 9221120237041090560n
11:27
<nicolo-ribaudo>
Which from your message above seems to be the spec-compliant behavior
11:28
<Aapo Alasuutari>
Yup, that's seems compliant. Ladybird also complies, based on a response I got in their Discord.
11:40
<Aapo Alasuutari>
https://issues.chromium.org/issues/408932085
11:48
<Aapo Alasuutari>
https://bugzilla.mozilla.org/show_bug.cgi?id=1958820
15:06
<shu>
where's the step that canonicalizes NaNs in sort?
15:08
<shu>
is it your reading that [[Get]] returns the ES NaN, then [[Set]] of that NaN should always produce the same bit pattern in typed arrays?
15:12
<shu>
anyway i think we should fix the spec to reflect reality, and clear up ambiguities in the reading
15:13
<shu>
i don't see a realistic path to get interoperable NaN canonicalization across engines, nor the benefits of doing so
17:29
<ljharb>
we had a whole day of discussion in 2015 about NaN canonicalization. my recollection was that the only time NaNs are canonicalized is when you see one in JS - not when a spec-internal operation gets or copies one
17:30
<littledan>
yeah not requiring canonicalization was a pretty explicit decision; I don't understand why we think this doesn't apply to sort
17:45
<annevk>
Not sure if this is what Aapo meant, but when I looked at https://tc39.es/ecma262/#sec-rawbytestonumeric earlier I could interpret that as normalizing NaN values. It checks if value is NaN and then it doesn't return value, but it returns (a canonical?) NaN.
17:50
<littledan>
When you write the JS NaN to a TypedArray, its byte pattern may be arbitrary: "If value is NaN, rawBytes may be set to any implementation chosen IEEE 754-2019 binary64 format NaN encoding. " https://tc39.es/ecma262/#sec-numerictorawbytes Actually, the text gives some guarantees that aren't actually met in all browsers: "An implementation must always choose the same encoding for each implementation distinguishable NaN value." I would prefer that we adopt Waldemar's proposed alternative, that we just delete that second sentence.
17:51
<littledan>
the committee was just a little over-optimistic that such regularity would fall out in engines like V8, but it doesn't
17:51
<littledan>
anyway I imagine sort hits this spec path, so it doesn't guarantee canonicalization
20:24
<Aapo Alasuutari>

Yeah, I was thinking of [[Get]] / RawBytesToNumeric and a misread of "The Number Type":

NaN values of the IEEE Standard are represented in ECMAScript as a single special NaN value.

I had interpreted this to mean that all NaNs must be canonicalised to a single one. Though, the NumericToRawBytes also linked above does indeed say that writing NaN should always choose the same NaN, so I did end up getting it right despite getting it wrong :D

20:30
<Aapo Alasuutari>
Since spec-wise, sort always performs a fully copy of the buffer data into a list of Values and back after sorting, it'll indeed always pass each entry in the TA through RawBytesToNumeric and NumericToRawBytes.
23:08
<akaster>
what's the best way to get this change (PR 2193) on someone's radar? queue it up for an upcoming TC39 meeting? something less formal?
23:35
<bakkot>
that PR is not currently correct and also needs tests
23:35
<bakkot>
so you will need to find a champion willing to do that work
23:35
<bakkot>
thus far no one has stepped forward
23:35
<bakkot>
I personally do not currently have time