Talk:Algorithm Implementation/Sorting/Smoothsort

This is a nice code example. However, for two reasons this implementation is not very practical:

(i) A really unfortunate choice is to require the type T to provide a swap  method. Most types and classes do not provide swap as one of its methods, and most types and classes (including built-in types) are not open to the user for adding such a method. For example, the code cannot be used to sort a simple array of ints because of that. The standard way (and the STL way) is to use a binary function void swap(T&,T&). Such a function can always be provided without having to edit the type T (which is often not possible). Ideally, one should be able to choose the swap function as argument of the algorithm.

(ii) The operator  >=  is used for comparison. This is not very flexible, especially in case one wants to use several different comparison criteria in the same code. A better way is to allow one to provide a comparison function to the sorting algorithm -- as is possible for the STL sorting algorithms. Moreover, the ">=" could be changed to the more commonly used <tt>less</tt>".

B.t.w: really bad style is "<tt>if(!(POINTER && NUMBER))</tt>..."

--130.183.84.216 16:45, 1 March 2007 (UTC)

Some issues regarding the current implementation.
First off, thanks for taking your time to comment on this implementation, I very much welcome your opinions.

Regarding your comments on the unfortunate choices:

Whilst struggling to decipher Dijkstra's original paper and actualy writing the code I took my sweet time to decide how to parameterize both the swapping and the comparison. Although its true, the STL does use a different approach, I don't see how this is by any means the "correct" or "most appropiate" way of doing things. As a matter of fact, and since the ultimate idea was to keep the code concise and direct, I believe making the implementation "STL compliant" would be too much work for nothing. Those of you who care to modify the code are more than welcome (I may be modifying this after all, but only if I find enough time to spare).

Along the same line: both the issues mentioned before can be easily solved if a "wrapper" class is implemented in place of the type parameter, even a parameterizable, STL compliant one. So this shouldn't be much of a problem.

Regarding your comments on "style":

I must disagree on this. Although there are way too many manuals of "style" there's simply no point on it, reformat/rewrite the code if this bothers you, in this case in particular its a single line and everybody who has read a C language manual knows what that means (this is a C++ implementation of the algorithm after all).

All in all, although I regard your comments as details which should be taken care of, I very much appreciate and welcome them, if I find the time I'll re-write the implementation to suit your needs.

Cheers

Changed the use of swap
I've changed the use of swap methods into swap functions. It was only used 4 places and doing so allows people to use the code on standard types without modifing the code in any way. I hope this is OK (given the discussion above, I believe it is). As to the use of >= over < -- I couldn't care less. The same goes to the use of "bad style". FrederikHertzum (talk) 22:58, 19 August 2008 (UTC)

Request for comments on the algorithm
First of all, thank you very much for your code.

I transcribed the original EWD796 to LaTeX a while ago, in order to do the same but I found that the way Dijkstra described the algorithm and his style of pseudocode simple was too alien to me. I hope that your code will help me in studying the algorithm.

Would you (if you have the chance and time) care to comment on the workings of the algorithm? The code helps immensely, but having someone who has implemented the algorithm describe it as well, would be even better.

''Just to say, i'm also reading the paper and trying to write an implementation (this time in java), and it is indeed utterly baffling. Why on earth did Dijkstra think this guarded command notation of his was a good idea? Most of the constructs map simply enough to normal languages, so there's nothing he wouldn't have had in one of those languages, and it has subroutines rather than procedures, so it doesn't have parameters or return values, which is a huge stumbling block in the path of understanding. That and his really unhelpful single-letter variable names, and the fact that he uses a few variables in the code without mentioning them at all in the text (all the ones ending in -1 or -2). It's not as if this all predates decent languages, either - he wrote that paper in 1981. I can't see any reason for it except obscurantism and arrogance. -- AnonymousCoder''

Comparison function should be external
Choice of using ">=" as the comparison function, and including it directly in the algorithm is a semantic error, because it mix different things in the same form. Extracting the comparison function is a difficulty, which shows the bad construction. For example, let's imagine we have to sort a table, with several indexes. Obviously, we cannot build several ">=" functions, and we do not want to use some 'tricks', or any complex construction. It would be much more easier (and clear) to select a comparison function for each index, if the algorithm could use these functions.

Improvements for the Delphi version
The Delphi version of this algorithm does function perfectly, great, and many thanks to the diligent programmer for (t)his work! But there are improvements possible: The isascending function is redundant(ly?) completely, simple comparisons have the same effect and use the computer ressources less. Moreover the +1 and -1 instructions can be replaced by the more efficent instructions succ and pred, and the additions and subtractions used for the same value with inc and dec.

Python version?
I'm wondering if someone could whip up a Python version of the algorithm that works. I've been unsuccessful in my attempts, and getting rather frustrated at my lack of progress...

Improvements for this algorithm
1. The both while loops in the main body (function) can be replaced by simple for loops because the number of loopings is determined (before the loop entry).

2. The both boolean operations „if b>=3 then“ in the main body or main function (building sorted array part) and „if b1>=3 then“ in the trinkle procedure seem to be redundant (unnessecary) because both variables never get the value 2 (this is a result of many experiments with different, also large numbers of sorting elements).

Sorting elements number limit of this algorithm
The number of sortable elements is limited when only 32 bit integers are used, especially with the 32th Leonardo number (7.049.155), and this number (ore one few) is the limitation for the number of sortable elements. Otherwise some variables have to be 64 bit integers, namly: b, b1, c, c1, p in the main procedure, vb and vc in the up and the down procedure and p1 in the trinkle procedure.

This algorithm is also in other or further programming languages available
Python at: https://github.com/toroidal-code/smoothsort-py

C#, VB.net, and PHP at: https://www.programmingalgorithms.com/algorithm/smooth-sort