Quale misura del disturbo usare quando si analizza Quicksort

Sto cercando di capire perché quicksort usando la partizione di Lomuto e un perno fisso sta funzionando in modo irregolare, ma nel complesso male, su input generati casualmente. Sto pensando che anche se gli input sono generati casualmente, le sequenze potrebbero essere molto ordinate, ma non sono sicuro di come misurare il livello di disturbo nelle sequenze. Ho pensato di utilizzare il numero di inversioni, ma ho visto da questa altra domanda che ho posto che in questo caso non è davvero una buona misura.

Il motivo per cui sospetto che le mie sequenze casuali abbiano un sacco di "ordine" per loro è che la randomizzazione del perno risolve il problema delle prestazioni. Ma teoricamente non dovrebbero esserci problemi di prestazioni su queste presunte sequenze di input "casuali".

La
partizione Lomuto vs Hoare soffre quando si ordinano chiavi uguali, mentre la partizione Hoare no.
Entrambi gli schemi di partizione soffrono allo stesso modo quando si utilizza un perno distante dalla mediana.

Misura del disturbo
La misura del disturbo da scegliere ai fini di quicksort è semplice.
A: Quanto è distante dalla mediana il perno fisso, rispetto ai dati casuali?
Se si insiste sull'uso della partizione di Lomuto e se si presuppone che siano consentiti valori duplicati, è necessario aggiungere il seguente test contro la casualità:
B: Quanti elementi duplicati ci sono, rispetto al casuale.

Ovviamente è piuttosto sciocco presumere che i valori duplicati siano consentiti nel tuo set di dati e valutare comunque la partizione di Lomuto, quindi dovresti probabilmente eliminare i duplicati in anticipo o passare alla partizione Hoare o supporre che i duplicati siano rari.

Entrambe le misure sono banali da quantificare utilizzando le statistiche.

Possiamo escludere dati patologici
Qualsiasi altra deviazione dalla casualità non avrà importanza ai fini dell'analisi di quicksort. Fintanto che il perno è vicino alla mediana funzionerà bene su tutti i dati non patologici.
La distanza dalla casualità dovrebbe essere davvero grande per essere patologicamente rapida, quindi possiamo escluderla.

Non usare mai alcun pivot fisso nel codice reale.
Nota che se scrivi un codice reale con un pivot fisso ^*) (qualunque sia quel pivot), ti stai aprendo a un attacco denial of service, perché un utente malintenzionato può inserire un valore patologico proprio in quel punto e quindi dovresti sempre scegliere un elemento casuale come perno.

*) o più pivot se scegli il meglio di x pivot.