ECMA-262 quote of the day

If comparefn is not `undefined` and is not a consistent comparison function for the elements of this array (see below), the behaviour of `sort` is implementation-defined.

[…]

A function comparefn is a consistent comparison function for a set of values S if all of the requirements below are met for all values a, b, and c (possibly the same value) in the set S: The notation a <CF b means comparefn(a,b) < 0; a =CF b means comparefn(a,b) = 0 (of either sign); and a >CF b means comparefn(a,b) > 0.

• Calling comparefn(a,b) always returns the same value v when given a specific pair of values a and b as its two arguments. Furthermore, Type(v) is Number, and v is not `NaN`. Note that this implies that exactly one of a <CF b, a =CF b, and a >CF b will be true for a given pair of a and b.
• Calling comparefn(a,b) does not modify the `this` object.
• a =CF a (reflexivity)
• If a =CF b, then b =CF a (symmetry)
• If a =CF b and b =CF c, then a =CF c (transitivity of =CF)
• If a <CF b and b <CF c, then a <CF c (transitivity of <CF)
• If a >CF b and b >CF c, then a >CF c (transitivity of >CF)
ECMA-262 3rd edition or ECMA-262 5th edition, 15.4.4.11 Array.prototype.sort (comparefn)

1. Could you explain the significance of this quote? What was the impetus of this post? I’m not picking up on it. Is it the inclusion of typical axioms for mathematical (in)equality?

Comment by Colby Russell — 01.03.10 @ 09:29

2. Here’s the impetus.

Comment by Jeff — 01.03.10 @ 11:38

3. If you do not want to follow the link, the link points you to the discussion on the non-randomness of the browser ballot due to the undefined behavior.

Comment by Havvy — 01.03.10 @ 16:38

4. Just curious, why would someone interested in knowing the impetus not be willing to follow the link?

Comment by Jeff — 01.03.10 @ 19:02