I was interested in this problem because I wanted to practice and I was bored.
Borrowed the Weights class and the knownBigs idea from Ryan McGuire, and the algorithm from Mert Sari
Most solutions come in at 16-21 sorts, but the odd one out takes 22.
Example which requires 22 sorts for mine:
[645, 327, 511, 540, 133, 440, 754, 210, 195, 694, 976, 331, 245, 348, 897]
The heavy lifter for keeping the sorts down seems to be the adding of the 3rd item when there are 2 currently big items. Tried a few ways to get the 3rd, this seems to be a decent one, but I am interested in a better. Tempted to make a knownSmaller with the reverse mappings of knownBigger, and use it to find the next item with the largest amount of comparisons showing he is big, although necessarily not as big as the biggest.