Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #29793 > unrolled thread

Bubblesort

Back to article view | Back to comp.lang.javascript

Contents

  Bubblesort jonas.thornvall@gmail.com - 2016-03-04 02:00 -0800
    Re: Bubblesort "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-03-04 18:53 +0800
      Re: Bubblesort "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-04 12:01 +0100
        Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-04 03:03 -0800
        Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-04 05:15 -0800
          Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-04 05:41 -0800
            Re: Bubblesort "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-03-04 21:56 +0800
            Re: Bubblesort Stefan Weiss <krewecherl@gmail.com> - 2016-03-04 15:10 +0100
              Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-04 07:37 -0800
                Re: Bubblesort Stefan Weiss <krewecherl@gmail.com> - 2016-03-04 17:08 +0100
              Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-04 07:50 -0800
              Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-04 07:54 -0800
                Re: Bubblesort Stefan Weiss <krewecherl@gmail.com> - 2016-03-04 17:21 +0100
                Re: Bubblesort Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-04 19:26 +0000
                  Re: Bubblesort "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-04 23:05 +0100
                  Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-05 09:15 -0800
                  Re: Bubblesort Stefan Weiss <krewecherl@gmail.com> - 2016-03-08 03:43 +0100
                    Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-08 02:41 -0800
                      Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-08 09:10 -0800
                  Re: Bubblesort Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-08 23:34 +0100
                    Re: Bubblesort Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-08 23:46 +0100
                    Re: Bubblesort Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-09 00:16 +0000
                      Re: Bubblesort Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-09 02:41 +0100
              Re: Bubblesort Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-08 23:35 +0100
                Re: Bubblesort Stefan Weiss <krewecherl@gmail.com> - 2016-03-09 02:38 +0100
                  Re: Bubblesort Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-09 22:04 +0100
                    Re: Bubblesort Stefan Weiss <krewecherl@gmail.com> - 2016-03-10 21:14 +0100
                      Re: Bubblesort Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-10 22:17 +0100
                        Re: Bubblesort "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-10 22:31 +0100
                          Re: Bubblesort Stefan Weiss <krewecherl@gmail.com> - 2016-03-10 23:25 +0100
                            Re: Bubblesort "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-11 00:16 +0100
          Re: Bubblesort "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-03-04 21:59 +0800
            Re: Bubblesort "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-04 17:12 +0100
            Re: Bubblesort Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-05 02:00 +0100
              Re: Bubblesort John Harris <niam@jghnorth.org.uk.invalid> - 2016-03-05 18:39 +0000
              Re: Bubblesort Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-05 17:40 -0800
        Re: Bubblesort "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-03-04 21:54 +0800
          Re: Bubblesort "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-04 16:59 +0100
      Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-04 03:04 -0800
        Re: Bubblesort jonas.thornvall@gmail.com - 2016-03-04 03:55 -0800
      Re: Bubblesort Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-05 00:01 +0100
        Re: Bubblesort Aleksandro <aleksandro@gmx.com> - 2016-03-06 18:41 -0300

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#29862

Thomas 'PointedEars' Lahn wrote:

> String comparison *can* be the default for Array.prototype.sort(); in
> fact, if the /comparefn/ argument is “undefined” (including not
> specified), the sort order is *implementation-dependent*.  Implementations
> need not agree on a default comparator.
> 
> So specifying a comparator is *required* in *portable* code *regardless*
> of the type of the elements (which can be of a different type each; but
> see Typed Arrays).
> 
> <http://www.ecma-international.org/ecma-262/6.0/index.html#sec-array.prototype.sort>

Supplemental:

JSX:array.js contains jsx.array.createComparator() which returns a reference 
to a custom comparator with which you can sort an array of (values 
convertible to) objects using their (then-)properties as sort keys.

Test case, with link to the documentated source code: 
<http://PointedEars.de/scripts/test/array>
  
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29863

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>
>> jonas.thornvall@gmail.com writes:
>> <snip>
>>> Sorry i bothered you your approach do indeed ***work***, apparently it
>>> is a string but i can't understand how random makes a string value.
>> 
>> Math.random() does not make a string but Array.prototype.sort() uses
>> string comparison by default.  It's documented.
>
> Imprecise.
>
> String comparison *can* be the default for Array.prototype.sort(); in fact, 
> if the /comparefn/ argument is “undefined” (including not specified), the 
> sort order is *implementation-dependent*.  Implementations need not agree on 
> a default comparator.

That is not how I read the document you cite.  The default comparator
*is* specified (it's 22.1.3.24.1 with /comparefn/ undefined) and the
resulting order is only implementation-defined in some rather particular
cases.

> So specifying a comparator is *required* in *portable* code *regardless* of 
> the type of the elements (which can be of a different type each; but see 
> Typed Arrays).

Portable code may properly rely on the specified properties of sort even
with an undefined /comparefn/.

> <http://www.ecma-international.org/ecma-262/6.0/index.html#sec-array.prototype.sort>

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29865

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> jonas.thornvall@gmail.com writes:
>>> <snip>
>>>> Sorry i bothered you your approach do indeed ***work***, apparently it
>>>> is a string but i can't understand how random makes a string value.
>>> 
>>> Math.random() does not make a string but Array.prototype.sort() uses
>>> string comparison by default.  It's documented.
>>
>> Imprecise.
>>
>> String comparison *can* be the default for Array.prototype.sort(); in
>> fact, if the /comparefn/ argument is “undefined” (including not
>> specified), the sort order is *implementation-dependent*. 
>> Implementations need not agree on a default comparator.
> 
> That is not how I read the document you cite.  The default comparator
> *is* specified

Nobody said that the default comparator would not be specified.

> (it's 22.1.3.24.1 with /comparefn/ undefined) and the resulting order is
> only implementation-defined in some rather particular cases.

Including these:

| The sort order is also implementation-defined if comparefn is undefined 
| and SortCompare (22.1.3.24.1) does not act as a consistent comparison 
| function.
| […]
| The sort order is also implementation defined if any of the following 
| conditions are true:
| 
| […]
| · If comparefn is undefined and the application of ToString to any value 
|   passed as an argument to SortCompare modifies obj or any object on 
|   obj’s prototype chain.
| · If comparefn is undefined and all applications of ToString, to any
|   specific value passed as an argument to SortCompare, do not produce the 
|   same result.
| 
| […]
| 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 obj or any object on obj’s
|   prototype chain.
| · 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)

| 22.1.3.24.1 Runtime Semantics: SortCompare( x, y )
| […]
| NOTE 2   Method calls performed by the ToString abstract operations in 
|          steps 5 and 7 have the potential to cause SortCompare to not
|          behave as a consistent comparison function.

Those are too many “rather particular cases” for my taste to risk omitting 
the specification of a comparator as argument.

>> So specifying a comparator is *required* in *portable* code *regardless*
>> of the type of the elements (which can be of a different type each; but
>> see Typed Arrays).
> 
> Portable code may properly rely on the specified properties of sort even
> with an undefined /comparefn/.

The specified properties alone do not lead to consistent results among 
implementations, especially not as not all implementations in use are 
conforming.  The record shows.

>> <http://www.ecma-international.org/ecma-262/6.0/index.html#sec-array.prototype.sort>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29861

Stefan Weiss wrote:

> On 03/04/2016 14:41, jonas.thornvall@gmail.com wrote:
>>> I thought this would sort the property "subarray" nodelinks.
>>>
>>>  arr[0].nodelinks.sort();
>>>
>>> But after sort it write out same content as before sort.
>>> 1,10,11,12,13,14,15,16,17,2,3,4,5,6,7,8,9
>>> […]
> 
> The result you describe is typically what you get when you use sort()
> with string elements instead of numbers. Ideally, you should make sure
> that you actually insert numbers into `arr[x].nodelinks`, not strings.

As Ben pointed out in <news:8737s6doyh.fsf@bsb.me.uk>, that would not help.
But see also my follow-up to his posting.
 
> Alternatively, you can sort string array elements using a numeric
> comparison function:
> 
>     arr[x].nodelinks.sort((a, b) => a - b);
> 
> Or in a more verbose form (but with better UA compatibility):
> 
>     function compareNumeric (a, b)
>     {
>         return a - b;
>     }
> 
>     arr[x].nodelinks.sort(compareNumeric);

For reasonable backwards-compatibility, the function declaration is 
unnecessary/unwise, unless the comparator is declared locally *and* used 
locally more than once (in which case a function declaration/variable 
initialization saves memory).  Function expressions are backwards-compatible 
down to JavaScript 1.3 and JScript 5.0 at least (Netscape Navigator 4.06+, 
Internet Explorer 5.0), therefore marked “safe” in the ECMAScript Support 
Matrix since its inception in 2005 (IIRC).

  arr[x].nodelinks.sort(function (a, b) { return a - b; });

<http://PointedEars.de/es-matrix/?filter=function>

This is also the equivalent syntax for the ECMAScript 2015 arrow function 
syntax as used above.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29864

On 03/08/2016 23:35, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> Alternatively, you can sort string array elements using a numeric
>> comparison function:
>>
>>     arr[x].nodelinks.sort((a, b) => a - b);
>>
>> Or in a more verbose form (but with better UA compatibility):
>>
>>     function compareNumeric (a, b)
>>     {
>>         return a - b;
>>     }
>>
>>     arr[x].nodelinks.sort(compareNumeric);
> 
> For reasonable backwards-compatibility, the function declaration is 
> unnecessary/unwise, unless the comparator is declared locally *and* used 
> locally more than once (in which case a function declaration/variable 
> initialization saves memory).

In this case, sort() is used in a loop.

> Function expressions are backwards-compatible 
> down to JavaScript 1.3 and JScript 5.0 at least (Netscape Navigator 4.06+, 
> Internet Explorer 5.0), therefore marked “safe” in the ECMAScript Support 
> Matrix since its inception in 2005 (IIRC).

I didn't mean to say that function declarations were more compatible
than function expressions. The second example is also "more verbose", it
was intended to show how a common comparison function can be made reusable.

The difference in memory usage should be minimal. A declared function
will remain in memory at least until it goes out of scope and can be
garbage collected (when no references to it are left). With function
expressions, no reference to the function is left after it has been used
to sort the array. I don't expect a measureable difference either way.


OT: You didn't mention performance, but I was curious and did a quick
test anyway: in current versions of Firefox and Chrome, there are no
huge differences, although referencing a previously created function is
consistently faster than using an inline expression, and traditional
functions are consistently faster than arrow functions. In Firefox 44,
inline arrow functions are noticably slower than the other variants
(about an order of magnitude).

By the way, const/let are also consistently slower than var, but not by
much. This may be caused by the additional checks required for the
"temporal dead zone".


- stefan

[toc] | [prev] | [next] | [standalone]

#29872

Stefan Weiss wrote:

> On 03/08/2016 23:35, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> Alternatively, you can sort string array elements using a numeric
>>> comparison function:
>>>
>>>     arr[x].nodelinks.sort((a, b) => a - b);
>>>
>>> Or in a more verbose form (but with better UA compatibility):
>>>
>>>     function compareNumeric (a, b)
>>>     {
>>>         return a - b;
>>>     }
>>>
>>>     arr[x].nodelinks.sort(compareNumeric);
>> 
>> For reasonable backwards-compatibility, the function declaration is
>> unnecessary/unwise, unless the comparator is declared locally *and* used
>> locally more than once (in which case a function declaration/variable
>> initialization saves memory).
> 
> In this case, sort() is used in a loop.

Then a local variable declaration with initialization (see below) or a local 
function declaration is appropriate, unless the function makes an closure 
over a name with a loop-variant value.

>> Function expressions are backwards-compatible down to JavaScript 1.3 and
>> JScript 5.0 at least (Netscape Navigator 4.06+, Internet Explorer 5.0), 
>> therefore marked “safe” in the ECMAScript Support Matrix since its 
>> inception in 2005 (IIRC).
> 
> I didn't mean to say that function declarations were more compatible
> than function expressions.

Nor did I imply that you did.

> The second example is also "more verbose", it was intended to show how a
> common comparison function can be made reusable.

That was reasonable, given the context of the question that I could not see 
(and did not want to consider here anyway).
 
> The difference in memory usage should be minimal. A declared function
> will remain in memory at least until it goes out of scope and can be
> garbage collected (when no references to it are left). With function
> expressions, no reference to the function is left after it has been used
> to sort the array. I don't expect a measureable difference either way.

I was recommending that if you need the same comparator more than once, you 
should not do so by using the same function expression more than once in an 
argument list.  So not

  var
    a = [3, 1, 2],
    b = [5, 6, 4],
    c = [8, 9, 7];

  a.sort(function (x, y) { return x - y; });
  b.sort(function (x, y) { return x - y; });
  c.sort(function (x, y) { return x - y; });

but instead

  var
    a = [3, 1, 2],
    b = [5, 6, 4],
    c = [8, 9, 7],
    f = function (x, y) { return x - y; };

  a.sort(f);
  b.sort(f);
  c.sort(f);

That an object is no longer referred to does not mean that it has been 
garbage-collected, so WLOG one must assume that every evaluation of a 
function expression creates a new object with the "old" one still reserving 
memory.

There might be internal optimizations in some implementations that would not 
create a new Function instance for the *same* function expression (but it 
would not be trivial to implement this, because of the closure); but it is 
unwise to rely on that.

BTW, who would be interested in a sort method that would be able to only 
sort parts of an array?
 
> OT: You didn't mention performance, but I was curious and did a quick
> test anyway: in current versions of Firefox and Chrome, there are no
> huge differences, although referencing a previously created function is
> consistently faster than using an inline expression,

I expected that.

> and traditional functions are consistently faster than arrow functions.

I did not expect that …

> In Firefox 44, inline arrow functions are noticably slower than the other
> variants (about an order of magnitude).

… that – so, are we, in the end, sacrificing performance for convenient 
syntax with arrow functions here? –,
 
> By the way, const/let are also consistently slower than var, but not by
> much. This may be caused by the additional checks required for the
> "temporal dead zone".

… or that.  Thank you for sharing this.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29878

On 03/09/2016 22:04, Thomas 'PointedEars' Lahn wrote:
> BTW, who would be interested in a sort method that would be able to only 
> sort parts of an array?

Maybe... what's the use case for this?

>> OT: You didn't mention performance, but I was curious and did a quick
>> test anyway: in current versions of Firefox and Chrome, there are no
>> huge differences, although referencing a previously created function is
>> consistently faster than using an inline expression,
> 
> I expected that.
> 
>> and traditional functions are consistently faster than arrow functions.
> 
> I did not expect that …
> 
>> In Firefox 44, inline arrow functions are noticably slower than the other
>> variants (about an order of magnitude).
> 
> … that – so, are we, in the end, sacrificing performance for convenient 
> syntax with arrow functions here? –,

You were right not to expect that... after rearranging my test script
and upgrading to FF45, I can't reproduce yesterday's results anymore.

The issue using sort() with inline arrow functions in Firefox still
exists, but the effect is much smaller when other array methods are
used. Sorting an empty array with FF45 (20m iterations each):

                 ms total   ns each
function_ref:         326        16
function_inline:      650        33
arrow_ref:            329        17
arrow_inline:        4571       229

The more elements the array has, the less pronounced the difference is,
so it's possible that this only affects function creation, not execution.

Apart from this, arrow functions are pretty much on par with traditional
functions.

>> By the way, const/let are also consistently slower than var, but not by
>> much. This may be caused by the additional checks required for the
>> "temporal dead zone".
> 
> … or that.  Thank you for sharing this.

I only see this in Chromium (tested v48 and v49; Opera is probably also
affected); there is no difference in Firefox or Edge. Here are the
results I get in Chromium 48 for the tests below:

      ms total  ns each
let:      2379      238
var:       205       21


    const ITERATIONS = 1e7;
    const TESTS = {
        "let": function (iter) {
            while (iter--) {
                let total = 0;
                for (let i = 0; i < 10; ++i) {
                    let a = i;
                    let b = -i;
                    let sum = a + b;
                    total += sum;
                }
                sideEffect += total;
            }
        },
        "var": function (iter) {
            while (iter--) {
                var total = 0;
                for (var i = 0; i < 10; ++i) {
                    var a = i;
                    var b = -i;
                    var sum = a + b;
                    total += sum;
                }
                sideEffect += total;
            }
        },
    };
    var sideEffect = 0;

Full test code here: http://pastebin.com/raw/AgRUxHCJ

- stefan

[toc] | [prev] | [next] | [standalone]

#29880

Stefan Weiss wrote:

> On 03/09/2016 22:04, Thomas 'PointedEars' Lahn wrote:
>> BTW, who would be interested in a sort method that would be able to only
>> sort parts of an array?
> 
> Maybe... what's the use case for this?

I am not certain.  When I was writing my follow-up, it just occurred to me 
that this might be a pretty neat idea (just like digital watches).  Perhaps 
I was thinking of table sections.

If there is only one part, then it is trivial, of course:

  var a = […];
  var partially_sorted =
    a.slice(0, 42).concat(a.slice(42, 47).sort(comparator), a.slice(47));

>>> In Firefox 44, inline arrow functions are noticably slower than the
>>> other variants (about an order of magnitude).
>> 
>> [I did not expect] that – so, are we, in the end, sacrificing performance 
>> for convenient syntax with arrow functions here? –,
> 
> You were right not to expect that... after rearranging my test script
> and upgrading to FF45, I can't reproduce yesterday's results anymore.
> 
> The issue using sort() with inline arrow functions in Firefox still
> exists, but the effect is much smaller when other array methods are
> used. […]
> Apart from this, arrow functions are pretty much on par with traditional
> functions.

ACK.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29883

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 10 Mar 2016 in 
comp.lang.javascript:

>> On 03/09/2016 22:04, Thomas 'PointedEars' Lahn wrote:
>>> BTW, who would be interested in a sort method that would be able to only
>>> sort parts of an array?

This one nicely sorts only the numerical parts in Chrome:

var arr = [3,2,5,'break',11,8,.5,'break',7,3];
var res = arr.sort((a, b) => a - b);
document.write(res); 

// Chrome: 2,3,5,break,0.5,8,11,break,3,7

// Edge: 0.5,2,3,5,break,3,8,11,break,7 

Seems very illogical in Edge, what is happening?


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29884

On 03/10/2016 22:31, Evertjan. wrote:
> This one nicely sorts only the numerical parts in Chrome:
> 
> var arr = [3,2,5,'break',11,8,.5,'break',7,3];
> var res = arr.sort((a, b) => a - b);
> document.write(res); 
> 
> // Chrome: 2,3,5,break,0.5,8,11,break,3,7
> 
> // Edge: 0.5,2,3,5,break,3,8,11,break,7 
> 
> Seems very illogical in Edge, what is happening?

This comparison function is unsuitable for non-numeric elements. If you
want to sort mixed-type arrays, you need to to define how your elements
compare to each other. Is "break" larger or smaller than 8? Is an object
larger or smaller than `true`?

The expression `a - b` evaluates to NaN if one or both of the operands
are non-numeric strings. As of ES2015, this is specified to be
interpreted as +0 by Array.prototype.sort. In other words, "break" in
your example is seen as equal to every other array element in the array.
That's not a stable sorting algorithm, and the result is what you see in
your test.

- stefan

[toc] | [prev] | [next] | [standalone]

#29885

Stefan Weiss <krewecherl@gmail.com> wrote on 10 Mar 2016 in 
comp.lang.javascript:

> On 03/10/2016 22:31, Evertjan. wrote:
>> This one nicely sorts only the numerical parts in Chrome:
>> 
>> var arr = [3,2,5,'break',11,8,.5,'break',7,3];
>> var res = arr.sort((a, b) => a - b);
>> document.write(res); 
>> 
>> // Chrome: 2,3,5,break,0.5,8,11,break,3,7
>> 
>> // Edge: 0.5,2,3,5,break,3,8,11,break,7 
>> 
>> Seems very illogical in Edge, what is happening?
> 
> This comparison function is unsuitable for non-numeric elements. If you
> want to sort mixed-type arrays, you need to to define how your elements
> compare to each other. Is "break" larger or smaller than 8? Is an object
> larger or smaller than `true`?
> 
> The expression `a - b` evaluates to NaN if one or both of the operands
> are non-numeric strings. As of ES2015, this is specified to be
> interpreted as +0 by Array.prototype.sort. In other words, "break" in
> your example is seen as equal to every other array element in the array.
> That's not a stable sorting algorithm, and the result is what you see in
> your test.

Okay:

var arr = [3,2,5,'break','break',11,8,.5,'break',7,3];

function f(a,b) {
	if ( a === b ) return 0; // ment[?] for equal strings
	if ( isNaN( a ) ) return 1; // strings to highest
	if ( isNaN( b ) ) return -1; // strings to highest
	return a - b;
};

var res = arr.sort(f);

document.write(res); // 0.5,2,3,3,5,7,8,11,break,break,break 


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29804

On 3/4/2016 9:15 PM, jonas.thornvall@gmail.com wrote:
>
> I thought this would sort the property "subarray" nodelinks.
>   arr[0].nodelinks.sort();
> But after sort it write out same content as before sort.
> 1,10,11,12,13,14,15,16,17,2,3,4,5,6,7,8,9
> My object something like this.
>        arr[k] ={nodelinks : []};

I don't know what you are trying to write or build. I seldom heard 
people doing elaborate mathematics with Javascript, which is used mainly 
for displaying web-pages.

Are you abusing if not misusing a tool here?

-- 
   @~@   Remain silent. Nothing from soldiers and magicians is real!
  / v \  Simplicity is Beauty! May the Force and farces be with you!
/( _ )\ (Fedora release 23)  Linux 4.4.3-300.fc23.x86_64
   ^ ^   21:42:01 up 19:51 0 users load average: 1.05 1.03 1.05
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#29813

"Mr. Man-wai Chang" <toylet.toylet@gmail.com> wrote on 04 Mar 2016 in 
comp.lang.javascript:

> On 3/4/2016 9:15 PM, jonas.thornvall@gmail.com wrote:
>>
>> I thought this would sort the property "subarray" nodelinks.
[..]
> 
> I don't know what you are trying to write or build.

I nearly never understand the specifics of Jonasses trials,
but that they have an unneccessary complexity 
caused by not trying to see the simple basics.

> I seldom heard people doing elaborate mathematics with Javascript, 

Does that have anything to do with the possibilities of Javascript?

I have never heard much about the possibilities of javascript,
usually I just read interesting scripts, read about scripts or write them.

> which is used mainly for displaying web-pages.

Same objection, Einstein used his brain to construct a theory [two, in fact] 
that no one had constructed before, and brains mainy are used for more 
mundane purposes.

While Jonases results perhaps are lacking, 
but his perceverance is to be admired.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29821

Mr. Man-wai Chang wrote:
^^^^^^^^^^^^^^^^^
Please post here using your real name.  If Man-wai Chang is your real name, 
you should omit the “Mr.”

> On 3/4/2016 9:15 PM, jonas.thornvall@gmail.com wrote:
>> I thought this would sort the property "subarray" nodelinks.
>>   arr[0].nodelinks.sort();
>> But after sort it write out same content as before sort.
>> 1,10,11,12,13,14,15,16,17,2,3,4,5,6,7,8,9
>> My object something like this.
>>        arr[k] ={nodelinks : []};
> 
> I don't know what you are trying to write or build. I seldom heard
> people doing elaborate mathematics with Javascript,

There is no Javascript, see the ECMAScript Support Matrix (signature below) 
for details.

> which is used mainly for displaying web-pages.

As there is no Javascript, it is not used.

ECMAScript implementations, e.g. the programming languages that are have 
“JavaScript” in their name, are multi-purpose programming languages.  In Web 
browsers, they are not “mainly used for displaying "web pages"”, but to make 
Web documents like HTML documents more dynamic and interactive, by use of 
implementations of APIs *with* them, for example the DOM.

But consider, for example, environments like Node.js.
 
> Are you abusing if not misusing a tool here?

No.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29826

On Sat, 05 Mar 2016 02:00:08 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Mr. Man-wai Chang wrote:
>^^^^^^^^^^^^^^^^^
>Please post here using your real name.  If Man-wai Chang is your real name,

That's ignorant or racist. Either way, it's stupid.

 
>you should omit the “Mr.”
  <snip>

Why? It's uncommon but uncommon is not the same as forbidden. Besides,
in some contexts leaving out the Mr, or whatever, is rude.

  John

[toc] | [prev] | [next] | [standalone]

#29828

Thomas 'PointedEars' Lahn wrote:

> Mr. Man-wai Chang wrote:
> ^^^^^^^^^^^^^^^^^
> Please post here using your real name.  If Man-wai Chang is your real name, 
> you should omit the "Mr."

Please post here using your real name.  If Thomas Lahn is your real name,
you should omit the 'PointedEars'.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29802

On 3/4/2016 7:01 PM, Evertjan. wrote:
>
> So bubble-sort, while a nice exercise for newbies, is probably much slower.
>

There are books on sorting algorithms, with maths to compare their 
efficiency. Well, I seldom need to reinvent the wheels. :)

-- 
   @~@   Remain silent. Nothing from soldiers and magicians is real!
  / v \  Simplicity is Beauty! May the Force and farces be with you!
/( _ )\ (Fedora release 23)  Linux 4.4.3-300.fc23.x86_64
   ^ ^   21:42:01 up 19:51 0 users load average: 1.05 1.03 1.05
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#29810

"Mr. Man-wai Chang" <toylet.toylet@gmail.com> wrote on 04 Mar 2016 in
comp.lang.javascript: 

> n 3/4/2016 7:01 PM, Evertjan. wrote:
>>
>> So bubble-sort, while a nice exercise for newbies, is probably much
>> slower. 
>>
> 
> There are books on sorting algorithms, with maths to compare their 
> efficiency. Well, I seldom need to reinvent the wheels. :)

Reinventing wheels is a nice design exercise for later 
when you want to design something more inventive.

In programming experience and understanding of something like bubblesort 
seems imho and ime good for your design skills, perhaps not for real 
invention.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29797

Den fredag 4 mars 2016 kl. 11:53:32 UTC+1 skrev Mr. Man-wai Chang:
> On 3/4/2016 6:00 PM, jonas.thornvall@gmail.com wrote:
> > I was thinking sorting links for each node, using a simple bubblesort, it is not that many links on each node usually. A link can't be equal to another so no "=" needed.
> > arr[i] contain the nodes and nodelinks[] is an array of links 1,4,2,3,0 for example.
> >
> > Does it seem in principal right?
> 
> Does Javascript have a function to sort arrays?
> 
> -- 
>    @~@   Remain silent. Nothing from soldiers and magicians is real!
>   / v \  Simplicity is Beauty! May the Force and farces be with you!
> /( _ )\ (Fedora release 23)  Linux 4.4.3-300.fc23.x86_64
>    ^ ^   18:42:01 up 16:51 0 users load average: 1.04 1.04 1.05
> 不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
> http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

Thank's Man-wai Chang

[toc] | [prev] | [next] | [standalone]

#29798

Den fredag 4 mars 2016 kl. 12:04:45 UTC+1 skrev jonas.t...@gmail.com:
> Den fredag 4 mars 2016 kl. 11:53:32 UTC+1 skrev Mr. Man-wai Chang:
> > On 3/4/2016 6:00 PM, jonas.thornvall@gmail.com wrote:
> > > I was thinking sorting links for each node, using a simple bubblesort, it is not that many links on each node usually. A link can't be equal to another so no "=" needed.
> > > arr[i] contain the nodes and nodelinks[] is an array of links 1,4,2,3,0 for example.
> > >
> > > Does it seem in principal right?
> > 
> > Does Javascript have a function to sort arrays?
> > 
> > -- 
> >    @~@   Remain silent. Nothing from soldiers and magicians is real!
> >   / v \  Simplicity is Beauty! May the Force and farces be with you!
> > /( _ )\ (Fedora release 23)  Linux 4.4.3-300.fc23.x86_64
> >    ^ ^   18:42:01 up 16:51 0 users load average: 1.04 1.04 1.05
> > 不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
> > http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
> 
> Thank's Man-wai Chang

I thought that this would do it but id doesn't sort the subobject/attribute array nodelinks. This is written out after call to arr[i].nodelinks.sort();
nodelinks is an array within the arr object/array.

1,10,11,12,13,14,15,16,17,2,3,4,5,6,7,8,9

// Sort links
function sortlinks()
{
   for(var i = 0; i < nodes; nodes ++ )
   {
     arr[i].nodelinks.sort();
   document.write(arr[i].nodelinks);p.stop();
   }
}

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web