Develop Reference

what is cut off value in sorting algorithms?

I was asked to do the quicksort, cut off with insertion sort. But I did not understand the meaning of cut off value. I need someone to elaborate this concept with real-world examples.

Some algorithms are asymptotically better than others. In your case, the asymptotic run time of Quicksort is O(N(logN)) while the asymptotic run time of insertion sort is O(N^2).
This means that for large values of N, Quicksort will run faster than insertion sort.
However, for small values of N, insertion sort may run faster. Hence, you can optimize the actual run-time of Quicksort by combining it with insertion sort for small array sizes.
Quicksort is a recursive algorithm, that breaks the original array into smaller arrays and runs recursively on each sub-array. Cut off with insertion sort means that once you reach array sizes smaller than some constant cut-off size, you sort these small arrays using insertion sort instead of continuing the recursion.

It is hard to be sure without seeing the exact statement of requirements.
However, I think that this means that you should use insertion sort (O(N^2)) below a certain size (the "cut off") and quicksort (O(NlogN)) above that size.
They could mean that you do this test on the size of the input array.
They could also mean that you implement a hybrid sort, and use insertion sort on a subarray when a quicksort partition size is less than the threshold.
Either interpretation is plausible.
I need someone to elaborate this concept with real-world examples.
I doubt that you need examples to understand this. If you understand the insertion sort and quicksort algorithms, then this is conceptually straightforward. (And if you don't understand them, there are lots of places to read about them, starting with your data structures & algorithms textbook.)

QuickSort Analysis with Pivot as a last Element in Array

I was wondering what the Big-O of this Array is when you use QuickSort:
6 8 7 5 9 4
4 is my Pivot element.
I thought it would be Best-Case with a complexity of O(nlogn), but I am not 100% sure.

The Big-O complexity of quicksort is quadratic (O(n^2)). this means that for every possible input, it will perform at least this fast (or slow, if you will).
As mentioned in comments, Big-O deals with theoretical worst-case scenario, not with a particular input. For a particular input, you can compute the absolute number of steps.
As an aside, quicksort is (was?) quite popular not for a good Big-O performance, but for good usual case performance on moderate input sizes - while there are algorithms that perform in O(n log n) (that's also theoretical limit - can't do better), they tended to be slower in practical use since they had larger constants (i.e. the asymptotically better performance only manifested itself on large inputs).

QuickSort vs MergeSort on arrays of primitives in Java

I know that Java's Arrays.sort method uses MergeSort for sorting arrays of objects (or collections of objects) since it is stable, and Java uses QuickSort for arrays of primitives because we don't need stability since two equal ints are indistinguishable, i.e. their identity doesn't matter.
My question is, in the case of primitives, why doesn't Java use MergeSort's guaranteed O(n log n) time and instead goes for the average O(n log n) time of QuickSort? In the last paragraph of one of the related answers here, it is explained that:
For reference types, where the referred objects usually take up far more memory than the array of references, this generally does not matter. But for primitive types, cloning the array outright doubles the memory usage.
What does this mean? Cloning a reference is still at-least as costly as cloning a primitive. Are there any other reasons for using QuickSort (average O(n log n)) instead of MergeSort (guaranteed O(n log n) time) on arrays of primitives?

Not all O(n log n) algorithms have the same constant factors. Quicksort, in the 99.9% of cases where it takes n log n time, runs in a much faster n log n than mergesort. I don't know the exact multiplier -- and it'll vary system to system -- but, say, quicksort could run twice as fast as merge sort on average and still have theoretical worst case n^2 performance.
Additionally, Quicksort doesn't require cloning the array in the first place, and merge sort inevitably does. But you don't have a choice for reference types if you want a stable sort, so you have to accept the copy, but you don't need to accept that cost for primitives.

Cloning a reference is still at-least as costly as cloning a primitive.
Most (or all?) implementations of Java implement an array of objects as an array of pointers (references) to objects. So cloning an array of pointers (references) would consume less space than cloning the objects themselves if the objects are larger in size than a pointer (reference).
I don't know why the term "cloning" was used. Merge sort allocates a second temp array, but the array is not a "clone" of the original. Instead an proper merge sort alternates the direction of merge from original to temp or from temp to original depending on iteration for bottom up, or depending on level of recursion for top down.
dual pivot quick sort
Based on what I can find doing web searches, Java's dual pivot quicksort keeps track of "recursions", and switches to heap sort if the recursion depth is excessive, to maintain O(n log(n)) time complexity, but at a higher cost factor.
quick sort versus merge sort
In addition to stability, merge sort can be faster for sorting an array of pointers (references) to objects. Merge sort does more moves (of the pointers) but fewer compares (of the objects accessed by dereferencing pointers), than quick sort.
On a system with 16 registers (most of them used as pointers), such as X86 in 64 bit mode, a 4-way merge sort is about as fast as regular quick sort, but I don't recall seeing a 4-way merge sort in a common library, at least not for a PC.

Arrays#sort(primitive array) doesn't use traditional Quick Sort; it uses Dual-Pivot Quicksort, which is faster than quicksort, which in turn is faster than merge sort, in part because it doesn't have to be stable.
From the javadoc:
Implementation note: The sorting algorithm is a Dual-Pivot Quicksort by Vladimir Yaroslavskiy, Jon Bentley, and Joshua Bloch. This algorithm offers O(n log(n)) performance on many data sets that cause other quicksorts to degrade to quadratic performance, and is typically faster than traditional (one-pivot) Quicksort implementations.

QuickSort is approximately 40% faster than MergeSort on random data because of fewer data movements
QuickSort requires O(1) extra space while MergeSort requires O(n)
P.S. Neither classic QuickSort nor MergeSort are used in Java standard library.

Why Arrays.sort is quicksort algorithm, why not another sort algorithm?

Why? Is it faster or more efficient?
For systems with one core, we can use quicksort. What should we use on systems with two cores, four cores, or eight cores?

Quicksort has the advantage of being completely in place, so it does not require any additional storage, while mergesort (which is actually used by Arrays.sort() for object arrays) and other (all?) guaranteed O(n*log n) algorithm require at least one full copy of the array. For programs that sort very large primitive arrays, that means potentially doubling the overall memory usage.

The answer is in Jon L. Bentley and M. Douglas McIlroy’s “Engineering a Sort Function”, which the sort function cites.
Shopping around for a better qsort, we found that a qsort written at Berkeley in 1983 would consume quadratic time on arrays that contain a few elements repeated many times—in particular arrays of random zeros and ones. In fact, among a dozen different Unix libraries we found no qsort that could not easily be driven to quadratic behavior; all were derived from the Seventh Edition or from the 1983 Berkeley function.…
Unable to find a good enough qsort, we set out to build a better one. The algorithm should avoid extreme slowdowns on reasonable inputs, and should be fast on ‘random’ inputs. It should also be efficient in data space and code space. The sort need not be stable; its specification does not promise to preserve the order of equal elements.
The alternatives were heapsort and mergesort, since Java was created in the early 1990s. Mergesort is less desirable because it requires extra storage space. Heapsort has a better worst-case performance (O(n log n) compared to O(n^2)), but performs more slowly in practice. Thus, if you can control the worst case performance via good heuristics, a tuned quicksort is the way to go.
Java 7 is switching to Timsort, which was invented in 1993 (implemented in Python in 2002) and has a worst-case performance of O(n log n) and is a stable sort.

Quicksort has O(n log n) average and O(n^2) worst case performance, that is the best "average case" a sort algorithm can be, there are other sort algorithms that have this performance, but quicksort tends to perform better than most.
See: http://en.wikipedia.org/wiki/Quicksort

It is a tuned quicksort. If you are really interested you can read the material mentioned in the documentation.
The sorting algorithm is a tuned quicksort, adapted from Jon L. Bentley and M. Douglas McIlroy's "Engineering a Sort Function", Software-Practice and Experience, Vol. 23(11) P. 1249-1265 (November 1993).
And here is a bit of an explanation - the tuned version gives n*log(n) on many data sets:
This algorithm offers n*log(n) performance on many data sets that cause other quicksorts to degrade to quadratic performance

Compared with Quicksort, Mergesort has less number of comparisons but larger number of moving elements.
In Java, an element comparison is expensive but moving elements is cheap. Therefore, Mergesort is used in the standard Java library for generic sorting
In C++, copying objects can be expensive while comparing objects often is relatively cheap. Therefore, quicksort is the sorting routine commonly used in C++ libraries.
ref: http://www.cs.txstate.edu/~rp44/cs3358_092/Lectures/qsort.ppt

Arrays.sort() uses multiple sorting algorithms depending on the size and elements in the array.
Insertion sort for small arrays
Merge sort for mostly sorted arrays
A highly tuned and adaptable dual-pivot & single pivot quicksort for everything else
So in practice we see that quicksort is very fast for large arrays of primitives but has some pitfalls when it needs to adapt to partially sorted arrays, when comparisons between objects are slow, for stable sorting and more.

Since its been a while since last answer on this thread, here is some updates...
It depend on the complexity and its relevancy to size of array plus probability when java researched these algorithms and just decided depending on Measurements and Benchmarks.
According to JAVA JDK 1.8 DOCS its self explanatory where it chooses the algorithm not
only one but up to four to choose from according to some thresholds...
/**
* If the length of an array to be sorted is less than this
* constant, Quicksort is used in preference to merge sort.
*/
private static final int QUICKSORT_THRESHOLD = 286;
/**
* If the length of an array to be sorted is less than this
* constant, insertion sort is used in preference to Quicksort.
*/
private static final int INSERTION_SORT_THRESHOLD = 47;
/**
* If the length of a byte array to be sorted is greater than this
* constant, counting sort is used in preference to insertion sort.
*/
private static final int COUNTING_SORT_THRESHOLD_FOR_BYTE = 29;
/**
* If the length of a short or char array to be sorted is greater
* than this constant, counting sort is used in preference to Quicksort.
*/
private static final int COUNTING_SORT_THRESHOLD_FOR_SHORT_OR_CHAR = 3200;
Reference Java DOC JDK 8
It event evolved to use parallel Sorting
Sorting in Java
Java 8 comes with a new API – parallelSort – with a similar signature to the Arrays.sort() API:
#Test
public void givenIntArray_whenUsingParallelSort_thenArraySorted() {
Arrays.parallelSort(toSort);
assertTrue(Arrays.equals(toSort, sortedInts));
}
Behind the scenes of parallelSort(), it breaks the array into different sub-arrays (as per granularity in the algorithm of parallelSort). Each sub-array is sorted with Arrays.sort() in different threads so that sort can be executed in parallel fashion and are merged finally as a sorted array.
Note that the ForJoin common pool is used for executing these parallel tasks and then merging the results.
The result of the Arrays.parallelSort is going to be same as Array.sort of course, it’s just a matter of leveraging multi-threading.
Finally, there are similar variants of API Arrays.sort in Arrays.parallelSort as well:
Arrays.parallelSort (int [] a, int fromIndex, int toIndex);
Summary:
So as the Java API evolves with the HardWare and software in general
there is more use for the multi threading and tuning here and there
on the thresholds and algorithims.

First of all Arrays.sort doesn't only use quick sort , It uses multiple algorithms java1.6 onwards
See below code from Arrays class
/**
* Sorts the specified array into ascending numerical order.
*
* Implementation note: The sorting algorithm is a Dual-Pivot Quicksort
* by Vladimir Yaroslavskiy, Jon Bentley, and Joshua Bloch. This algorithm
* offers O(n log(n)) performance on many data sets that cause other
* quicksorts to degrade to quadratic performance, and is typically
* faster than traditional (one-pivot) Quicksort implementations.
*
* #param a the array to be sorted
*/
public static void sort(int[] a) {
DualPivotQuicksort.sort(a);
}
DualPivotQuicksort.sort(a); // This uses 5 algorithms internally depending upon dataset size
do checkout the source code of Arrays class.
Before java 1.6 I think it was using three algorithm quick sort for primitive types such as int and mergesort for objects and when quick sort out performs it start heap sort, See here for more details
http://cafe.elharo.com/programming/java-programming/why-java-util-arrays-uses-two-sorting-algorithms

Quicksort is fastest on average O(n log(n)), so Sun probably used that as a good metric.

QuickSort is a common sorting algorithm. It's reasonably fast, except when the data to be sorted is already in inverse order. It's also efficient in space.

It depends on what you want to do. The problem with a normal quicksort is, that it can sometimes be in O(n²). So normaly you could use heap sort, but most times quick sort is faster.
However the Arrays.sort(...) implementation uses a "tuned tuned quicksort, adapted from Jon L. Bentley and M. Douglas McIlroy [...]" (according to the JavaDoc documentation). This algorithm has has some build in optimizations, that enables it to work on O(n*log(n)), where a normal quicksort would use O(n²).
Also the Arrays.sort algorithm is tested over and over again and you can be sure that it works and is bugfree (although this can't be guaranteed.)
iuiz

Arrays.sort() does not use quick-sort.
Java 7 used TimSort which is a combination of Merge Sort and Insertion Sort.
Java 8 uses parallel-sort when there are more number of elements, and uses multiple threads for sorting. Else it uses TimSort.
Thus the worst case time complexity is always O(nlogn)

What is the difference between quicksort and tuned quicksort?

What is the fundamental difference between quicksort and tuned quicksort? What is the improvement given to quicksort? How does Java decide to use this instead of merge sort?

As Bill the Lizard said, a tuned quicksort still has the same complexity as the basic quicksort - O(N log N) average complexity - but a tuned quicksort uses some various means to try to avoid the O(N^2) worst case complexity as well as uses some optimizations to reduce the constant that goes in front of the N log N for average running time.
Worst Case Time Complexity
Worst case time complexity occurs for quicksort when one side of the partition at each step always has zero elements. Near worst case time complexity occurs when the ratio of the elements in one partition to the other partition is very far from 1:1 (10000:1 for instance). Common causes of this worst case complexity include, but are not limited to:
A quicksort algorithm that always chooses the element with the same relative index of a subarray as the pivot. For instance, with an array that is already sorted, a quicksort algorithm that always chooses the leftmost or rightmost element of the subarray as the pivot will be O(N^2). A quicksort algorithm that always chooses the middle element gives O(N^2) for the organ pipe array ([1,2,3,4,5,4,3,2,1] is an example of this).
A quicksort algorithm that doesn't handle repeated/duplicate elements in the array can be O(N^2). The obvious example is sorting an array that contains all the same elements. Explicitly, if the quicksort sorts the array into partitions like [ < p | >= p ], then the left partition will always have zero elements.
How are these remedied? The first is generally remedied by choosing the pivot randomly. Using a median of a few elements as the pivot can also help, but the probability of the sort being O(N^2) is higher than using a random pivot. Of course, the median of a few randomly chosen elements might be a wise choice too. The median of three randomly chosen elements as the pivot is a common choice here.
The second case, repeated elements, is usually solved with something like Bentley-McIlroy paritioning(links to a pdf) or the solution to the Dutch National Flag problem. The Bentley-McIlroy partitioning is more commonly used, however, because it is usually faster. I've come up with a method that is faster than it, but that's not the point of this post.
Optimizations
Here are some common optimizations outside of the methods listed above to help with worst case scenarios:
Using the converging pointers quicksort as opposed to the basic quicksort. Let me know if you want more elaboration on this.
Insertion sort subarrays when they get below a certain size. Insertion sort is asymptotically O(N^2), but for small enough N, it beats quicksort.
Using an iterative quicksort with an explicit stack as opposed to a recursive quicksort.
Unrolling parts of loops to reduce the number of comparisons.
Copying the pivot to a register and using that space in the array to reduce the time cost of swapping elements.
Other Notes
Java uses mergesort when sorting objects because it is a stable sort (the order of elements that have the same key is preserved). Quicksort can be stable or unstable, but the stable version is slower than the unstable version.

"Tuned" quicksort just means that some improvements are applied to the basic algorithm. Usually the improvements are to try and avoid worst case time complexity. Some examples of improvements might be to choose the pivot (or multiple pivots) so that there's never only 1 key in a partition, or only make the recursive call when a partition is above a certain minimum size.
It looks like Java only uses merge sort when sorting Objects (the Arrays doc tells you which sorting algorithm is used for which sort method signature), so I don't think it ever really "decides" on its own, but the decision was made in advance. (Also, implementers are free to use another sort, as long as it's stable.)

In java, Arrays.sort(Object[]) uses merge sort but all other overloaded sort functions use
insertion sort if length is less than 7 and if length of array is greater than 7 it uses
tuned quicksort.