Great job! This is a pretty well-written program that implements the algorithms to a T, and you even made sure to avoid integer overflow in your mean calculation! Now let's get down to everything you could do differently:
Comments
You use them too much. Consider this line:
int min; //Index of the minimal element during each runVariable names should explain themselves and code comments should generally be reserved for tricky logic. min is probably fine; if you want to be absolutely clear, you might change it to indexOfMin. Also, you don't need to declare it before the loop. If it gets re-assigned every time through the outer loop, then declare it in the outer loop. This way it's obvious the effects don't pass through loop iterations.
In
else if (less(tempArray[j], tempArray[i])) { //If the item on the right is smalleryour method name should make it clear what it does, and the comment is unnecessary. Also, traditionally Java methods returning booleans are of the form 'isAdjective', so this code would turn into
else if (isLess(tempArray[j], tempArray[i])) {I think it's more clear, though, to stick to what's already defined for us:
else if (tempArray[j].compareTo(tempArray[i]) < 0) {This makes it clear to me that the thing on the left is less than the thing on the right, though I could potentially see it both ways.
public static void mergeSort(Comparable[] toSort, Comparable[] tempArray, int low, int high) { //Recursively splits the array in half and then merges in proper order Not only does this comment make the line way too long, it should probably be a JavaDoc, not a comment.
Naming
int N = toSort.length;Speaking of naming, this line is a big no-no. I forget if Algorithms uses this or not, but names starting with an uppercase letter are always reserved for classes. Also, N is a bit vague. I would do
int length = toSort.length;Declarations
public static void insertionSort(Comparable[] toSort, int start, int end) {I understand you use this later in mergeSort, but your public-facing API should be consistent, and this isn't. Instead, have something like
public static void insertionSort(Comparable[] toSort) { insertionSort(toSort, 0, toSort.length);}private static void insertionSort(Comparable[] toSort, int start, int end) { ...This way your merge sort can still call it, but end-users who want insertion sort don't have to provide start and end points. Alternately, you could decide to add start and end parameters to every method, in case people only want to sort a subset of the array. In this case, still provide public methods without these extra parameters. The same goes for quickSort.
public static void mergeSort(Comparable[] toSort, Comparable[] tempArray, int low, int high)public static void mergeArrays(Comparable[] toSort, Comparable[] tempArray, int low, int mid, int high)On a related note, neither of these be public. End users don't really have anything to gain from these methods, so they should be marked private.
Spacing
for (int i=0; i < N; i++) { min = i; for(int j = i+1; j < N; j++) { if(less(toSort[j], toSort[min])) { min = j; } } swap(toSort, i, min);}You should keep a consistent style. If you put a space between for and (, always put a space between for and (.
if (high<=low + 15) {Spaces should be generally used to group terms together by precedence. + is evaluated before <=, so this could be high <= low+15. If you like lots of space, you could use high <= low + 15. If you don't like space, you could use high<=low+15. However, in my opinion this snippet is actually misleading. You're not trying to show that high is at least 15 more than low, you're trying to show that the difference between 'high' and 'low' is less than 15. Others might disagree, but I would always write 'high-low <= 15'.
Other
private static boolean equals(Comparable x, Comparable y) { return x.compareTo(y) == 0;}Aside from using compareTo directly in your methods, this method has no reason to exist. It's simply not used. However, you're right to not use the builtin equals in this case: the contract does not require that the comparison be consistent with equals.
Others have made wonderful points, and I particularly urge the use of generics - integers are comparable, and strings are comparable, but you can't really compare integers to strings. I also agree with the use of JavaDocs and unit tests.