If you're running Windows, then check out the app I made for animating them. It shows the assignment counts and comparison counts.
I measure the number of item assignments rather than swaps because it's easy to record that from the overloaded assignment operator (yeah that's C++). Also because some algorithms don't work by swapping, (like data_insert) and it doesn't make for a sensible comparison when several algorithms just always show zero.
Your sorting project compiles and runs fine for me in code blocks under windows. What I couldn't figure out is why the version with a mere flag is beating the version with the float limit in every case.
However, upon running my own sorting demo app, I was eventually able to find an ordering where the float-limit strategy pays off. One example is where the data is ordered as if you visited a balanced binary tree in pre-order traversal. e.g. (3, 1, 0, 2, 5, 4, 6)
So, although the flag version came out faster here, the float-limit version often performs fewer comparisons and should fare better for real-world sized items where the cost of the item comparisons outweighs the tiny assembly differences that give the flag version an advantage here.
sorry, the only thing I could picture about the optimized quicksort implementation was
because it's very similar to
if (low == high) return;
when left is incremented until it encounters right.
if (left == right) return;
actually, I don't know how a quicksort works together with an insertion sort :confused: .