This is marginally away from the submitter's question, but it warrnats attention:
The sad truth is that, as far as optimization goes, this isn't where attention is most needed.
Before we start worrying about things like saving two cycles here and there, we need to start teaching people how to select the proper algorithm for the task at hand.
There are too many programmers who spend hours turning their code into unreadable mush for the sake of squeezing a few milliseconds out of a loop that runs on the orde
Heh. Wasn't that long ago that every other guy's homegrown 3D engine (software rendering, mind you, this was the 100mhz pentium era) had an ultra-optimized version of bubblesort doing the depth sorting of polygons in a painter's algorithm type affair.
I certainly hope those people are better educated these days.
Grrr, you named the algorithm that must not be named! Cursed be the name of the fool who thought it would be a good algorithm for introductory students - I've lost count of the number of people convinced that this satan-spawned algorithm is faster than an insertion sort (it's not) and that there's no reason for them to learn to use the qsort() function. N.B., not to implement a quick sort, but to simply call a standard library routine.
The most frustrating thing is that, if you must use the algorithm that
Hehe.
Heard about bogosort?
Use random permutations and check if you have the data sorted.
The many-worlds version of bogosort is the fastest possible sorting algorithm though. Its O(C). For those that don't know, the many-worlds version just does one random permutation, with a new universe being created for each possible outcome of the permutation. You then destroy all the universes were the dataset isn't sorted.
You then destroy all the universes were the dataset isn't sorted.
Maybe collapse is a better word here? Although this was always the part where my understanding started walking out the door... (ie: wouldn't this experientially be like rolling a couple dice and then exploding my own universe if it didn't come up boxcars?)
Algorithms, Not Stupid Processor Tricks (Score:5, Insightful)
The sad truth is that, as far as optimization goes, this isn't where attention is most needed.
Before we start worrying about things like saving two cycles here and there, we need to start teaching people how to select the proper algorithm for the task at hand.
There are too many programmers who spend hours turning their code into unreadable mush for the sake of squeezing a few milliseconds out of a loop that runs on the orde
Re:Algorithms, Not Stupid Processor Tricks (Score:0)
I certainly hope those people are better educated these days.
The algorithm that must not be named! (Score:5, Funny)
The most frustrating thing is that, if you must use the algorithm that
Re:The algorithm that must not be named! (Score:0)
Heard about bogosort?
Use random permutations and check if you have the data sorted.
One of my friends implemented it once. It could sort arrays with as many as 14 elements in them
Re:The algorithm that must not be named! (Score:4, Funny)
The many-worlds version of bogosort is the fastest possible sorting algorithm though. Its O(C). For those that don't know, the many-worlds version just does one random permutation, with a new universe being created for each possible outcome of the permutation. You then destroy all the universes were the dataset isn't sorted.
Re:The algorithm that must not be named! (Score:2)
You then destroy all the universes were the dataset isn't sorted.
Maybe collapse is a better word here? Although this was always the part where my understanding started walking out the door... (ie: wouldn't this experientially be like rolling a couple dice and then exploding my own universe if it didn't come up boxcars?)
Re:The algorithm that must not be named! (Score:3, Funny)
The programmer will be alive in the universes which bogosort worked well.