Today, I have data (and code) that confirms the distribution is sorting-algorithm-dependent.  For each sorting algorithm, 1,000,000 instances of the list {0,1,2,3,4} were sorted with a random comparison function and the relative frequencies (rounded to the nearest whole percent) of each number in each position were computed.

The distributions are significantly different among these sorts.  QuickSort appears to provide a uniform distribution.  I believe that this is because QuickSort will only compare a particular pair of elements once, whereas each of the other sorting algorithms may compare a given pair of elements more than once (and with a random comparison function, receive a different result from one time to the next).

Here is the Mathematica notebook I used to generate this data: Randomize by Sorting.nb.  As noted in the file, some of the code for the sorting algorithms was taken from other locations and may be/is subject to their copyrights and/or license terms (I reasonably believe that this use complies with their licenses and/or constitutes fair use.  Also, some algorithms exhibited improper behavior when trying to sort lists with duplicate entries using a normal comparison function as noted in the file, though this should have no effect on the data above.

The second result in a google search for “javascript sort” says:

To randomize the order of the elements within an array, what we need is the body of our sortfunction to return a number that is randomly <0, 0, or >0, irrespective to the relationship between “a” and “b”. The below will do the trick:

//Randomize the order of the array:
var myarray=[25, 8, "George", "John"]
myarray.sort(function() {return 0.5 - Math.random()}) //Array elements now scrambled

This is almost exactly the method of randomization used in the browser ballot javascript.

To test the results of this randomization technique, I applied it 1,000,000 times to the list {0,1,2,3,4} in Mathematica and tabulated the relative frequencies of each number in each position. (Rounded to the nearest whole %).

At a glance, it appears that the distribution is far from uniform.  My quick attempt at re-learning how to use the Χ² test gave a probability less than 1×10^-100000 that this data matched a uniform distribution (if someone can confirm/fix that, please comment).

I used the Mathematica Sort[] command to do the sorting.  I don’t know what algorithm that uses.  It appears that the algorithm used by Javascript’s sort() varies from browser to browser, though the browser ballot would be displayed in IE8 by default.  I suspect that the distribution is highly dependent on the sorting algorithm used, though I cannot readily verify it [edit: I verified it].  Regardless, this seems to be a very poor way to generate a random ordering.

I stumbled into Fluid when I was looking for a way to keep my RememberTheMilk task list open on the side somewhere rather than always having a Firefox tab devoted to it (and trying to remember not to just close the Firefox window).  With Fluid, not only do I have an app dedicated to my RTM task list (and, since installing Gears into Safari^* makes it available to Fluid SSBs, it should have some ability to function offline, too), but I was able to create a separate menu-extra type app with the gadget interface to RTM so I can also access my task list quickly in the menu bar.

Having done that, it was a short skip over to having a proper Google Calendar app.  Nothing special there yet, save for the same hope that Gears will make it work offline.

More usefully, I found this post about using Fluid and Hahlo along with some scripting to create a pretty good Twitter client that even uses Growl notifications.  That post has all the links you need, including a direct link for the script and a link to a usable icon on Flickr.

Better still, it occurred to me tonight to apply Fluid to Lala.  With Fluid’s option to hide the window when the user closes it, rather than actually closing it, I can “close” the window that has Lala and it keeps playing.  If I go back to my Lala SSB app, the window pops right back up.

Mind you, while all this web-app-turned-mac-app stuff is nice, the biggest benefit is probably the fact that if my web-browsing browser crashes, it doesn’t take my web apps with it and no one of my web apps can crash the others.  Unfortunately, Webkit seems to share one big cookie jar among all its instances, so separate Fluid-created instances won’t allow you to simultaneously log into the same site using different credentials if you couldn’t already do so (the login cookies will clobber each other and/or any such Safari cookies… though Firefox’s cookie jar is separate from Webkit’s…).

^*note that, interestingly, the Gears site displays an essentially blank page with no help or guidance whatsoever if you have javascript turned off in Safari (I mast have been testing something or other without javascript and forgotten to turn it back on).