JavaScript core bug: Array.sort

frenzie

frenzie

Originally posted by missingno:

Fun fact: InsertionSort and MergeSort (used by Apple and Mozilla) are stable, QuickSort (Google Chrome) is not (by default). Chrome will sort arrays using InsertionSort if the array has 10 or less elements. So I suppose your code above ~~will~~may give another result if using 11 or more items in the array in Chrome. (Or Google already changed to another sorting algorithmn.)

I thought Opera/Presto 10+ is also stable. Although I guess the OP proves that wrong?

Originally posted by softmoonwebware:

I expect:
orders===[
{count: 4, name: "Bob", item: "bar"},
{count: 7, name: "Jack", item: "bar"},
{count: 4, name: "John", item: "foo"},
{count: 12, name: "Kelly", item: "baz"},
{count: 7, name: "Sara", item: "bar"},
{count: 3, name: "Tim", item: "buz"} ]

Now I take the array and sort it further by number of items ordered, so I can fill my big$$$ orders first:
orders.sort(function(a,b) {return a.count-b.count;});

I expect the names to remain ordered when the count is the same:
orders===[
{count: 3, name: "Tim", item: "buz"},
{count: 4, name: "Bob", item: "bar"},
{count: 4, name: "John", item: "foo"},
{count: 7, name: "Jack", item: "bar"},
{count: 7, name: "Sara", item: "bar"},
{count: 12, name: "Kelly", item: "baz"} ]

In a situation where my program requires and relies on two-step ordering (perhaps two separate functions are called in order, with the choice of functions dependent on program state, to deliver a final ordering) Opera will fail.

Umm, all of that works exactly that way in Opera 12.16 for me.

softmoonwebware

softmoonwebware

Originally posted by Frenzie:

Originally posted by softmoonwebware:

I expect:
orders===[
{count: 4, name: "Bob", item: "bar"},
{count: 7, name: "Jack", item: "bar"},
{count: 4, name: "John", item: "foo"},
{count: 12, name: "Kelly", item: "baz"},
{count: 7, name: "Sara", item: "bar"},
{count: 3, name: "Tim", item: "buz"} ]

Now I take the array and sort it further by number of items ordered, so I can fill my big$$$ orders first:
orders.sort(function(a,b) {return a.count-b.count;});

I expect the names to remain ordered when the count is the same:
orders===[
{count: 3, name: "Tim", item: "buz"},
{count: 4, name: "Bob", item: "bar"},
{count: 4, name: "John", item: "foo"},
{count: 7, name: "Jack", item: "bar"},
{count: 7, name: "Sara", item: "bar"},
{count: 12, name: "Kelly", item: "baz"} ]

In a situation where my program requires and relies on two-step ordering (perhaps two separate functions are called in order, with the choice of functions dependent on program state, to deliver a final ordering) Opera will fail.

Umm, all of that works exactly that way in Opera 12.16 for me.

Gotta admit I never tried it. But then it must be how that specific Array-arrangement ends up sorting anyway; when the Array has more or less entries, or a different starting order, will it still work? If the original example that started this post changes the original order due to lazy-quick algorithms, then it MAY change any other ordered-Array that has random entries and random ordering functions.
But if Opera 18 were just a descent browser as a user's browser goes, then the comment by the moderator would be relevant, that Opera 18 is NOT lazy. But I won't be using 18 because it doesn't even have bookmarks! How many others will still use 12.16 like me? When will HTML5 applications be truly possible? Why would Opera release a less-powerful browser that should be a BETA release for testing, not the primary download available for new users? The answers are all blowing in the wind...

frenzie

frenzie

Originally posted by softmoonwebware:

How many others will still use 12.16 like me?

Most of the posters in this thread. Possibly even all if you replace 12.16 with Presto.

sgunhouse

sgunhouse Moderator Volunteer

Everyone who runs Linux has to be using Presto, as no Blink-based versions have been released for that platform yet. Me - on Windows I use the latest versions (including test versions), in Linux I use 12.16.

Deleted User

Deleted User

Originally posted by softmoonwebware:

But I won't be using 18 because it doesn't even have bookmarks! How many others will still use 12.16 like me? When will HTML5 applications be truly possible? Why would Opera release a less-powerful browser that should be a BETA release for testing, not the primary download available for new users? The answers are all blowing in the wind...

Opera 18 (Blink) isn't a BETA release for testing. It is a final version as were 15, 16 and 17.
Opera ASA believes that their new product is mature enough to satisfy the needs of the masses (average users) which it is primarily aimed for.
Developement of Opera 12.16 (Presto) has ceased.
Opera 12.16 (Presto) and the new Opera (Blink) 15, 16, 17, 18, .... are totally different products. Only thing they have in common is the Opera-logo.
The new Opera (Blink) is basically Google Chrome with a different shell.

BTW, I'm also using the defunct Opera Presto and it doesn't look like I'll make the switch to the new product anytime soon if ever.

missingno

missingno

Originally posted by softmoonwebware:

So then my complaint is that Opera is just slack.

Depends. I would assume Carakan (Opera's JS-engine) uses QuickSort-algorithmn because it is a good general purpose sorting algorithmn to begin with. (Although I don't have any insight on this.)

Originally posted by serious:

PS: OT: "relying on js" discussion: There is a distinct difference between relying on JS (as in: webapp using only an API to communicate with the server) which is not a big deal these days vs. relying on JS for validation of user input (which is very bad).

I would differentiate between "using JS" and "relying on JS". You should never rely on JS, but you might use it for some parts. For example, if you have to sort an array to display it in your frontend, I wouldn't mind if the client manipulates the result as that only affects his side. But if you store the array back on the server side and "rely" on the data in it, I would have to validate anyways. So in this case, it doesn't make sense to do the sorting on the client side, but rather do everything on the server side and only send the results (which the client may manipulate, but I don't care as the server is still consistent).

frenzie

frenzie

Originally posted by missingno:

But if you store the array back on the server side and "rely" on the data in it, I would have to validate anyways. So in this case, it doesn't make sense to do the sorting on the client side, but rather do everything on the server side and only send the results (which the client may manipulate, but I don't care as the server is still consistent).

+1

softmoonwebware

softmoonwebware

Originally posted by missingno:

I would differentiate between "using JS" and "relying on JS". You should never rely on JS, but you might use it for some parts. For example, if you have to sort an array to display it in your frontend, I wouldn't mind if the client manipulates the result as that only affects his side. But if you store the array back on the server side and "rely" on the data in it, I would have to validate anyways. So in this case, it doesn't make sense to do the sorting on the client side, but rather do everything on the server side and only send the results (which the client may manipulate, but I don't care as the server is still consistent).

Amazing how you miss the point altogether.

You are still in the era of using _area- -/area_ tags:

The server sends an image-area and a JavaScript form.
{subsection A}
The user clicks on several check/radio buttons on the form, and types in data in input fields.
The user hits submit button.
The server validates the data.
The server processes the data and sends a new modified image-area, along with the entire page, most of which has nothing to to with this image-area.
--repeat subsection A --several times-- (overworking an already overloaded server) until the user is satisfied with the state of the image.
Now the user clicks on the image-area (it is a color picker).
The data of the user-click is sent to the server, processed into a hex-color, rgb color, etc. in a computationally intense process, again overworking the server (unnecessarily, because __we can't rely on JavaScript__), and the entire web page is resent, but with another form field filled in with the user-selected color from the image-area.
And we still haven't even mentioned that somehow this process has to keep track of WHICH color-selection-input is getting filled. Remember, we cannot rely on js!
Now the user does all this over and over again, waiting patiently for the server all along..... In fact, every "live" action like this needed must be sent to the server for processing.
After half-an-hour of back-and-forth data transfer, the user finally has a complex web-form filled out (with many fields being being the selected colors mentioned above). The form is dynamic to properly represent all the needed data, so every time the form needs new fields added or fields removed, a special submit button must be pressed by the user, and the server will add or remove the proper (new or old) fields, and send the page back to the server, keeping track of every POSTed variable to properly set the form inputs to the previous user-selections.
The user finally submits the fully completed form with another separate submit button (the form has 100 or so throughout that do various different things - a real swamp of an _application_ if you can really call it that)
The server validates and processes the data, refills the form with the POSTed data, and sends a new web page including a new graphical-image (besides the color-picker image mentioned above) developed from the user-sent data.
The entire process repeats until the user is finished, an hour later.

Or we could _rely_ on JavaScript. All this could be done on the user's machine without pestering the server. In fact, we don't even need the server, a static HTML page can reside on the user's harddrive and used anywhere, anytime. We can save the final image to hard drive, or perhaps send it to a server, fully processed.
Relying on JavaScript to do the job, the user is done in 10 minutes, and the server is free to serve pages not process sub-data for every little user-interaction.

We USE JavaScript to _enhance_ the user's browsing experience on a public server-sent __web-page__ that MUST work for every poor user with a computer from the year 2000 with MSIE6 and/or JavaScript turned off. HTML5 desktop apps _rely_ on JS.

Any time an __app__ needs to do some work, the server should be minimally involved, if at all.

softmoonwebware

softmoonwebware

Originally posted by missingno:

I would differentiate between "using JS" and "relying on JS". You should never rely on JS, but you might use it for some parts. For example, if you have to sort an array to display it in your frontend, I wouldn't mind if the client manipulates the result as that only affects his side. But if you store the array back on the server side and "rely" on the data in it, I would have to validate anyways. So in this case, it doesn't make sense to do the sorting on the client side, but rather do everything on the server side and only send the results (which the client may manipulate, but I don't care as the server is still consistent).

In my case, I _rely_ on JavaScript to sort an array of HTML Elements, moving one to the top, and then to apply individual CSS classnames to each one representing different CSS z-levels. If it doesn't work, the user cannot even use the application to let the server validate the final result.

In your analysis, the data cannot even BE displayed to the user properly.

And you would produce an application that displays mixed-up data to the user, asking him _is this data OK and ready to be submitted?_
He says no, because things are out of order...but when he tries to fix it, it re-orders itself wrong again and again...until he goes to the competition's website and buys the product there.

Originally posted by missingno:

I wouldn't mind if the client manipulates the result as that only affects his side

That is a poor excuse for work done. Take some pride in what you do, and do the best quality job you know how. Even if you clean toilets for a living.

missingno

missingno

Originally posted by softmoonwebware:

In my case, I _rely_ on JavaScript to sort an array of HTML Elements, moving one to the top,

Well, we can argue about terminology here. I would say you are _using_ JavaScript to move an element in an array. While your methology by "sorting" it gives you the result, the underlying algorithmn may change the order of other elements in the array which is an unwanted side-effect to you.

Your other example of a color picker also doesn't need any server involved, because you're still _using_ JavaScript to do so. The server doesn't need to know if the client picks black or white or red or blue or any other color. Maybe the result is sent to the server, but then you cannot rely on the data to be accurate at all, because the client could send "banana" or "cat".