This has come up before and we are not the only ones who are not using a stable sort. Also, heap sort is not stable either so this changelist does not change our sorting from stable to not stable.
-- Mads On 9/24/08, Lasse R.H. Nielsen <[EMAIL PROTECTED]> wrote: > True.Currently Firefox is stable, IE is consistently anti-stable (apparently > consistently puts similarly compared items in the opposite of the original > order - according to my rather small test), and Safari is unstable. > I think that leaves us with room enough to be unstable too. > > /L > > On Wed, Sep 24, 2008 at 6:29 PM, Christian Plesner Hansen < > [EMAIL PROTECTED]> wrote: > >> >> The problem with having a non-stable sort (and undefined behavior >> really) is that programs may end up depending on whatever behavior we >> have, spec-mandated or not. If our behavior is implementation >> dependent then changing the implementation may break people's >> programs. If we choose a simple and well-defined behavior, and >> stability is an obvious choice, then it becomes easier to maintain >> that behavior across changes to the implementation. >> >> On Wed, Sep 24, 2008 at 5:53 PM, Lasse R.H. Nielsen <[EMAIL PROTECTED]> >> wrote: >> > The specification does not require the sort to be stable (in fact, it >> > specifically says it doesn't have to be stable). >> > The Compare function is defined in the preceding code. It treats >> undefined >> > specially, and then, if there is a user provided comparison function it >> uses >> > that, otherwise it does string conversion and comparison. >> > /L >> > >> > On Wed, Sep 24, 2008 at 5:39 PM, William Hesse <[EMAIL PROTECTED]> >> wrote: >> >> >> >> There is no problem about the sort being stable or not, is there? Is >> the >> >> compare always the built-in >> >> arithmetic one? >> >> >> >> On Wed, Sep 24, 2008 at 2:34 PM, <[EMAIL PROTECTED]> wrote: >> >>> >> >>> LGTM, except for the following comments. >> >>> >> >>> >> >>> >> >>> http://codereview.chromium.org/4065/diff/1/2 >> >>> File src/array.js (left): >> >>> >> >>> http://codereview.chromium.org/4065/diff/1/2#oldcode724 >> >>> Line 724: if (IS_ARRAY(this)) { >> >>> This piece of code should still be needed. If we remove array holes, >> we >> >>> have to restore the length afterwards. >> >>> >> >>> http://codereview.chromium.org/4065/diff/1/2 >> >>> File src/array.js (right): >> >>> >> >>> http://codereview.chromium.org/4065/diff/1/2#newcode674 >> >>> Line 674: var pivot_index = global.Math.floor(global.Math.random() * >> (to >> >>> - from)) + from; >> >>> We need to make sure that we use the original Math.floor and >> Math.random >> >>> so that user-defined versions of Math.random do not interfere with >> >>> this >> >>> code. See for instance date-delay.js that introduces and uses $floor >> >>> and $abs for the original versions of Math.floor and Math.abs. >> >>> >> >>> http://codereview.chromium.org/4065 >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> We can IMAGINE what is not >> >> >> >> >> > >> > >> > >> > -- >> > Lasse R.H. Nielsen >> > [EMAIL PROTECTED] <[EMAIL PROTECTED]> >> > 'Faith without judgement merely degrades the spirit divine' >> > >> > > >> > >> >> > >> > > > -- > Lasse R.H. Nielsen > [EMAIL PROTECTED] > 'Faith without judgement merely degrades the spirit divine' > > > > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
