Unstable order of descending sorts

[fbennett]

A user style (the user being the UN Economic Commission for Latin America and the Caribbean) returns varying year-suffix assignments on each refresh of a wordprocessor document.

adamsmith isolated the issue to descending sorts. The descending sort function in csl.js was returning undefined for matching keys. The patch returns zero instead, which produces a stable result.

If this could be pushed and released fairly soon, it would be splendid.

[ajlyon]

I saw those lines in csl.js and thought: "Well, that's a pretty straightforward. -1 and +1. There can't be any problem with that." I think I'll have to keep my day job.

Thanks for looking at this with fresh and processor-aware eyes.

[fbennett]

Replying to fbennett:

A user style (the user being the UN Economic Commission for Latin America and the Caribbean) returns year-suffix assignments on each refresh of a wordprocessor document.

adamsmith isolated the issue to descending sorts. The descending sort function in csl.js was returning undefined for matching keys. The patch returns zero instead, which produces a stable result.

If this could be pushed and released fairly soon, it would be splendid.

[simon]

(In [6519]) closes #1717, Unstable order of descending sorts (thank to Frank)

[fbennett]

As the world knows, I messed up; the first patch filed broke sorting on several, perhaps many styles.

The followup, sort-refix.patch, has been confirmed to fix descending-sort stability in the ECLAC style, and to work with the Oecologia for which the breakage was first reported.

[fbennett]

Still problems with second-tier keys. Chicago Author-Date is coming up with a descending sort on the second key, where the first key matches.

​http://forums.zotero.org/discussion/14151/bibliography-not-in-alphabetical-order-as-per-selected-style/#CommentBody_69696

I don't fully understand how the sorting code works in csl.js, but the attached sort-darerefix.patch change produces the expected result for Chicago Author-Date, and a stable sort for ECLAC. It's an intuitive change more than anything else; the comment to the code I've commented out says that it was introduced to produce a stable sort, and it looks as though it converts what is trying to flip a 0 (equivalent) result one way or the other. If the other change (introducing the zero in the earlier block) stabilizes the ECLAC sort, possibly this later block is not necessary.

Seems to work with my limited testing, anyway.

[dstillman]

(In [6620]) Fixes #1717, Unstable order of descending sorts

[fbennett]

Another reproducible error, against the third patch, and on this trip back to the code I spotted the original source of the ECLAC stability error -- it was a silly thing, hiding in plain sight. The attached changefile "the-right-fix.patch" reverts previous changes and inverts the sort using 0 > x and x > 0, rather than 1 > x and x > 1.

This issue has called back so often it deserves its own ringtone.

​http://www.youtube.com/watch?v=rW9-FOLG-iA&feature=fvst

[dstillman]

(In [6633]) Fixes #1717, Unstable order of descending sorts, maybe