Dopo aver visto come funziona la ricorsione in Scheme dobbiamo valutare un altro aspetto molto rilevante: il costo. Non tutto ciò che logicamente funziona funziona poi all’atto pratico. Ad esempio, se ripescate la funzione ricorsiva della Funzione di Fibonacci e provate a farla partire noterete che già con numeri relativamente bassi (come 100) il sistema inizierà a intasarsi e non darà alcun risultato se non quello di dover killare il processo.

Perché questo? Perché l’implementazione dell’algoritmo, sebbene sia vera e matematicamente corretta, necessita un numero troppo elevato di calcoli o di memoria.

Iniziamo col dare dei cenni sulla complessità di un algoritmo. La complessità di un algoritmo è definita asintoticamente con un infinito di ordine superiore a una funzione f(x). In questo caso si dice che l’algoritmo ha complessità dell’ordine di f(x).

Cosa significa? E’ semplice. Supponete di far valere 1 il costo di ogni operazione base come somma, prodotto, cdr, car e via dicendo (ovviamente è un approssimazione). Supponete di stabilire un contatore che sommi il costo di ogni operazione eseguita. Supponete poi di eseguire questa funzione (con relativo contatore) per un imput di dimensione 1, poi per un input di dimensione 2, poi per un input di dimensione 3 e così via. La serie di numeri che otterrete non sarà altro che i valori di una funzione f(x)al variare di x. La complessità si riduce quindi all’ordine di infinito di questa funzione.

Data l’asintoticità della definizione, solitamente si trascurano i valori per x piccolo e si approssima molto per x che tende a infinito.

Senza addentrarci nei particolari sappiate che in ogni algoritmo esiste un operazione, detta operazione dominante, la quale complessità è uguale alla complessità dell’algoritmo nella sua interezza.

Negli algoritmi ricorsivi l’operazione dominante è la ricorsione. Per trovare la complessità di una funzione in scheme (che sono per definizione tutte ricorsive) ci basta quindi sapere quante volte una funzione chiama la ricorsione.

Questo può essere molto complicato, ma è giusto che impariate a identificare almento i casi semplici. Questo può essere fatto molto semplicemente.

Supponiamo di voler calcolare la complessità dell’algoritmo fattoriale visto qualche lezione fa. L’espressione ricorsiva del fattoriale è la seguente:

Per trovare il costo basta seguire la formula:

Questo perché il costo di f(0) è chiaramente unitario. Il costo di f(n), per il principio dell’operazione è solamente il costo della ricorsione e il costo della ricorsione non è altro che 1 più il costo di tutte le altre funzioni invocate.

Ma siamo arrivati ad una suluzione? Ancora no. Dobbiamo esplicitare il costo ovvero toglierlo dalla sua forma ricorsiva. Per fare ciò possiamo semplicemente espandere la seconda equazione.

• C[f(n)]
• 1 + C[f(n-1)]
• 2 + C[f(n-2)
• ...
• n + C[f(0)]
• n+1
• che è asintoticamente O(n)

Il costo è quindi lineare. (Non esattamente… ma per non mettere troppa carne al fuoco farò alcune precisazioni al riguardio nella prossima appendice).

Una funzione con complessità lineare è solitamente una funzione discretamente veloce e potente.

Vediamo ora la stessa cosa con la Funzione di Fibonacci.

La situazione è leggermente più complessa. Per esplicitare la funzione possiamo comunque espandere C[f(n)] ma non conviene in questo caso. Facciamo un ragionamento più sottile. Cerchiamo di calcolare direttamente il costo totale. Sappiamo che ogni ricorsione chiama due ricorsioni. Alla prima ricorsione avremo costo totale 1, alla seconda avremo il costo totale di prima più il costo delle due nuove ricorsioni ovvero 1 + 2. Alla terza avremo il costo di prima  più le due ricorsioni nuove lanciate da ognuna delle due ricorsione precedenti ovvero 1 + 2 + 4 (il costo di prima più le due ricorsioni nuove lanciate da ognuna delle due ricorsione precedenti).

Notiamo che abbiamo una serie geometrica che possiamo riassumere in 2^n+1 – 1 che asintoticamente è O(2^n).

Il costo è esponenziale. Un algoritmo esponenziale può solitamente calcolare solo input molto piccoli. Ecco perché il nostro algoritmo di Fibonacci si bloccava anche con numeri piccoli come 100.

Come possiamo allora migliorare questo algoritmo? Esistono tecniche un po’ più elaborate che permettono di eseguire algoritmi simili lanciando solo una ricorsione al posto delle due “canoniche”. Queste tecniche le esploreremo più in là in quanto necessitano di un po’ di esperienza.

Per il momento vi basti intuire che algoritmi che eseguono troppe ricorsioni contemporaneamente sono spesso troppo costosi per essere utili. Infatti abbiamo visto che basta lanciare due ricorsioni in vece di una per fare esplodere il costo da lineare ad esponenziale.

Non vi serve saper calcolare la complessità di tutto ma vi basta intuire quando un algoritmo sta diventando troppo costoso. Questo è basilare per ogni programmatore, anche al di là di Scheme.

Provate a calcolare il costo di altre funzioni di esempio che ho dato in precedenza. Postate il costo che avete ottenuto nei commenti e vedrò di verificare se avete indovinato.

L'algoritmo di Bubble Sorting in azione.

Insertion Sort e Selection Sort non si sono rivelati all’altezza delle nostre aspettative e noi ci ritroviamo ancora senza un algoritmo efficente per ordinare, o meglio: sappiamo ordinare le tracce di un album, oppure i CD di un apiccola collezione domestica, ma avremo molte difficoltà nell’ordinare in ordine di età gli abitanti di Roma o i volumi di un agrande biblioteca.

Dobbiamo proseguire la nostra ricerca, cambiamo approccio, questa volta il nostro tentativo cade sul Bubble Sort.

Il Bubble Sort deriva il suo nome dal comportamento degli elementi da ordinare sotto l’effetto di questo algoritm: essi infatti sembrano “risalire” l’array come bollicine nell’acqua minerale (si nota bene nell’animazione a lato).

BubbleSort(array[], elemN)
  alto = elemN
  changed = True
  while (alto > 0 and changed = True) :
    change = False
    for i = 0 to alto - 1 :
      if (array[i] > array[i + 1]) :
        tmp = array[i]
        array[i] = array[i + 1]
        array[i+1] = tmp
        changed = True
    alto = alto - 1

Il meccanismo di fondo è molto semplice: finchè alto (che l’indice che indica la “sommità” dell’array) rimane maggiore di zero ed è stato effettuato almento uno scambio (indicato dalla variabile changed) inizio una scansione dall’inizio fino ad alto dell’array e ogni volta che trovo un elemento maggiore del successivo, scambio i due elementi di posto.

E’ chiaro quindi che il Bubble Sort ha la capacità di accorgersi se un array è già ordinato (infatti se un array è ordinato non entra mai nel if per resettare la variabile changed e questo provoca l’uscita dal while) nel qual caso effettuerà soltanto la scansione di controllo con consto O(n).

Il caso peggiore è ovviamente un array ordinato al contrario. In questo caso infatti ogni scansione serve a posizionare con scambi successivi un solo elemento. Quindi avremo che in totale l’algoritmo ha costo O(n²).

Esatto anche lui. Anche il Bubble Sort si comporta come l’Insertion e il Selection Sort. Nessun vantaggio allora?

In realtà no. Un piccolo passo l’abbiamo fatto. Il Bubble Sort ci permette, con la sua capacità di fermarsi quando un array è ordinato, di eseguire inserimenti ordinati (ovvero inserimenti che mantengono l’ordine) con costo costante nel caso peggiore di O(n). Infatti non dobbiamo fare altro che sfruttare lo stesso meccanismo per scambiare elemento dopo elemento l’elemento da inserire (inizialmente in testa) fino alla sua posizione naturale.

Quindi ora, dato un array ordinato, sappiamo fare inserimenti ordinati, ma dobbiamo trovare ancora un metodo per ordinare l’array di partenza.

La nostra ricerca non è finita qui. Possiamo fare di meglio. Proveremo con il Quick Sort. Sperando che sia Quick.

Rappresentazione grafica di un ordinamento con Selection Sort

Nell’ultimo appuntamento abbiamo visto e analizzato gli aspetti generali dell’Insertion Sort e notato che esso non è affatto un algoritmo usabile in pratica per istanze (ovvero input) molto grandi.

Ovviamente l’Insertion Sort non è l’unico algoritmo di sorting esistente. Nella nostra ricerca dell’algoritmo ottimo di sorting oggi guarderemo il Selection Sort.

for i = 0 to n-2 :
    min = i
    for j = (i + 1) to n-1 :
        if A[j] < A[min] :
            min = j
    swap A[i] and A[min]

Il principio su cui si basa il Selection Sort è veramente molto semplice. In pratica dato un array A, seleziona il minimo e lo mette in testa, poi, nel sotto-array di dimensione n-1 seleziona il minimo e lo mette in seconda posizione… e cosi via. Vediamolo con un esempio.

8i 4 5 6 2 3 min=2
2 4i 5 6 8 3 min=3
2 3 5i 6 8 4 min=4
2 3 4 6i 8 5 min=5
2 3 4 5 8i 6 min=6
2 3 4 5 6 8 (finito)

Il problema di questo algoritmo è che la ricerca del minimo in un passo non da alcuna informazione su quale sia il minimo nel passo successivo. Per questo motivo ad ogni passo, indipendentemente dall’ordinamento dell’input, dobbiamo effettuare la suddetta ricerca. Quindi, poiché la ricerca del minimo ha costo lineare, al primoi passo dovremo pagare n, poi n-1, poi n-2, finché non avremo ordinato tutto l’array.

Ovvero n  + (n-1) + (n -2) + … + 1 e quindi, parimenti all’Insertion Sort, la complessità sarà di O(n²)! Con la differenza che il Selection Sort rimane quadratico anche per un input già ordinato.

Data la quadraticità dell’algoritmo possiamo effettuare integralmente le stesse considerazioni di “tempo di calcolo” che facevamo con l’Insertion Sort.

Anche il selection sort quindi è un algoritmo molto sconveniente. La nostra ricerca deve quindi proseguire.

Come ordina l'insertion sort.

Volevo discutere in qualche articolo alcuni problemi di algoritmica presentando alcuni algoritmi che li risolvono e analizzandone la complessità.

Cominciamo questa vetrina di algoritmi con quelli che risolvono il più classico dei problemi: l’ordinamento.

In particolare cominceremo vedendo uno dei più semplici: insertion sort.Insertion Sort :

def insertion_sort(x[], n) :
    for i = 1 to n - 1 :
        app = x[i]
        j = i - 1
        while (j >= 0) and (x[j] > app) :
            x[j + 1] = x[j]
            j = j - 1
        x[j + 1] = app

L’algoritmo segue un procedimento molto semplice. Insertion Sort utilizza due indici: uno che punta all’elemento da ordinare (i) mentre l’altro comincia dall’elemento che precede il primo indice e va decrescendo (j). All’inizio viene messo in app il valore puntato dal primo indice. Se l’elemento puntato dal secondo indice è maggiore di app i due elementi vengono scambiati di posto e decrementato j, altrimenti il valore di app viene copiato in j, il primo indice viene incrementato di uno e infine j resettato.

Vediamo un esempio, supponiamo un array di prova:

5 3 7 2 8 4

All’inizio avremo i due indici cosi inizializzati:

j5 i3 2 8 4 app=3

ed eseguiremo i seguenti passi:

j3 i5 2 8 4 app=3
3 j5 i2 8 4 app=2
3j 2 i5 8 4 app=2
2 3 j5 i8 4 app=8
2 3 5 j8 i4 app=4
2 3 j5 4 i8 app=4
2 j3 4 5 i8 app=4

2 3 4 5 8

In pretica il meccanismo alla base dell’insertion sort è quello di selezionare un elemento con i ed andarlo ad inserire nel suo posto facendolo spostare piano piano verso sinistra.

Ma quanto è oneroso computazionalmente questo algoritmo? Nel caso migliore app è sempre minore dell’elemento puntato da j e quindi banalmente l’algorimto termina dopo aver scandito ogni casella dell’array.

Ma l’analisi dei costi va fatta analizzando caso peggiore (e spesso il caso medio). Nell’insertion sort il caso peggiore equivale a quando j deve scandire tutto il sotto-array dall’inizio alla fine, ovvero quando l’array è ordinato al contrario. In questo caso al primo ciclo avremo che j farà 1 passo, al secondo ciclo ne farà 2 e così via.

Questo ci dice che in un array di dimensione n avremo che j farà in totale:

1 + 2 + ... (n-1)

Che in forma chiusa equivale a:

n(n-1) / 2

Ovvero, per n che tende a infinito, j fa un numero di iterazione che cresce come una funzione quadratica: ovvero l’algoritmo ha complessità O(N²).

Ma quantifichiamo questa cosa in termini pratici. Prendiamo il nostro calcolatore ideale di esempio e supponiamo di aver un calcolatore che esegua (molto ottimisticamente) ogni iterazione in 1 nanosecondo e supponiamo di voler ordinare un array X di 40MB di interi. 40MB di interi, poichè ogni intero è composto da 4 byte, equivale ad un array con 40.000.000 / 4 elementi. Ovvero n = 10.000.000.

Poichè insertion sort ha complessità quadratica per ordinare X eseguirà 10^14 iterazioni (sono centomila miliardi di iterazioni). Poichè ogni operazione è eseguita in un nanosecondo il nostro calcolatore è in grado di fare 10^9 operazioni al secondo (un miliardo di operazioni al secondo). Quindi per ordinare l’array impiegherà 10^5 secondi = 100.000 secondi = 27.7 ore che è circa un giorno.

Poichè, invece, nel caso migliore abbiamo che il costo è lineare, nel caso migliore il nostro calcolatore impiegherà 10^-2 secondi ovvero un centesimo di secondo.

Quindi un applicazione che utilizza insertion sort, su grandi moli di dati ha un gap di complessità di 10^5/10^-2 = 10^7!! Ovvero il tempo che impiega la vostra applicazione può variare da pochi centesimi di secondo ad un giorno solo a causa di un input!!!

Decisamente inaccettabile per qualunque applicazione rispettabile. L’insertion sort è quindi grosso modo bocciato: è da tener presente però che può trovare validità per ordinare quantità piccole di dati soprattutto grazie alla sua capacità di essere in place, ovvero di non richiedere più memoria di quella dell’array dato in input.

Nel prossimo articolo continueremo la ricerca del miglior algoritmo di ordinamento, proveremo con il Selection Sort.