In parecchie applicazioni informatiche, specie in quelle simulative, saper integrare una funzione ricopre un ruolo fondamentale. Purtroppo però le tecniche di integrazione che ci hanno insegnato a scuola o nei corsi di Analisi I sono del tutto inutili. Raramente, infatti, ci troveremo a che fare con funzioni integrabili, anzi, spesso dovremo integrare funzioni non esprimibili tramite funzioni analitiche.

Supponete ad esempio di voler implementare un piccolo gioco di guida. La prima cosa da fare è progettare il nostro sistema di guida. Ovviamente, dato che siamo dei tipi tosti, vogliamo che sia il più realistico possibile e non c’è nulla di più realistico che usare le leggi della fisica.

Supponiamo che il giocatore controlli direttamente l’accelerazione della macchina (una supposizione molto ragionevole) e che tale accelerazione sia descritta da una funzione a(t). A meno che il vostro giocatore non sia un androide o una specie di divinità è plausibile pensare che l’accelerazione imposta alla macchina non sia una precisa funzione analitica bensì un guazzabuglio di accelerate e frenate e, anche se il pilota è talmente bravo da accelerare seguendo una funzione analitica, voi non potreste sapere in anticipo quale funzione sia. Nonostante ciò dovete derivare lo stesso questa funzione sconosciuta per ricavare la velocità (e integrare di nuovo per ottenere la posizione della macchinina): non avete altra scelta che usare dei metodi di integrazione numerica.

I metodi di integrazione numerica permettono di stimare l’integrale di una funzione conoscendo solamente il suo valore in un insieme finito di punti. Ho selezionato tre metodi elencati in ordine di complessità. Esistono anche alcuni metodi più precisi (come, ad esempio, i metodi di integrazione gaussiana) ma necessitano di molti più calcoli e non sono quindi adatti all’uso “informatico” se non in alcuni campi specifici.

Metodo dei Rettangoli

Questo metodo è sicuramente il più semplice e, di contro, il meno preciso. Supponiamo di voler integrare una funzione f(x) nell’intervallo [a,b]. Per fare ciò dividiamo l’intervallo in n intervalli di dimensione delta.

Ogni rettangolo avrà un area di f(x1)*delta. Per stimare il nostro integrale ci basta sommare i contributi di ogni rettangolo. Ovviamente, più il numero di intervalli è alto più il nostro integrale sarà ben approssimato.

Una versione delmetodo dei rettangoli in python è data dal seguente codice:

Total è l’accumulatore del risultato. Il puntatore i va da a a b con passo delta scandendo quindi intervallo per intervallo la funzione da integrare (rappresentata da function2).

Metodo dei Trapezi

Il metodo dei trapezi è la logica estensione del metodo dei rettangoli. Invece di calcolare l’area del rettangolo di base delta e altezza f(x_n) calcoliamo l’area del trapezio il cui lato ubiquo unisce f(a+n*delta) con f(a+(n+1)*delta).

Il metodo è molto più preciso e può essere scritto in python con una sola riga

Metodo di Cavalieri-Simpson

Il metodo migliore è però il metodo di Cavalieri-Simpson. Il metodo approssima due intervalli con una parabola passante per il punto in comune fra i due.

Ogni coppia di intervalli ha come integrale

Dove h è la dimensione di un intervallo, y0 è il valore della funzione nel primo estremo del primo intervallo, y2 è il valore della funzione nel secondo estremo e y1 è il valore della funzione nell’estremo in comune.

L’algoritmo in python è il seguente

Confronti

Ho eseguito un breve test sui tre metodi eseguendo il seguente integrale:

Test con 10 intervalli

• Rettangoli : 2.124518813379953
• Trapezi: 1.6517198689244215
• Simpson: 1.658728115119567

Già con soli 10 intervalli notiamo che il metodo di Simpson ha un errore inferiore al millesimo.

Test con 100 intervalli

• Rettangoli : 1.7055620908116773
• Trapezi: 1.6582821963661236
• Simpson: 1.6583476291805812

Test con 1000 intervalli

• Rettangoli : 1.6630749297713836
• Trapezi: 1.6583469403268327
• Simpson: 1.6583475942223707

Per un test più preciso bisognerebe eseguire il test anche per molti altri tipi di funzione. In ogni caso, se vi trovate a dover integrare una funzione in un vostro programma, ora, sapete come fare.

Supponiamo di trovarci in una città a noi sconosciuta e di avere un appuntamento importante con una stupenda ragazza (o ragazzo a seconda dei casi). La cosa più semplice da fare è chiedere indicazioni ai passanti. Purtroppo però siamo sfortunati e quel giorno diluvia che dio la manda e non c’è anima viva in giro. Non c’è speranza.

LA RICERCA IN AMPIEZZA

In questo caso l’unica soluzione che avete è di tentare tutte le strade. Partite dal punto A e verificate tutti gli incroci a cui si arriva direttamente da A, se non siete arrivati tornate ad A e verificate tutti gli incroci a cui si arriva partendo da A e attraversando un solo incrocio, e così via, aumentanto ad ogni passo la profondità della ricerca. Questo tipo di ricerca prende il nome di ricerca in ampiezza. Funziona? Sicuro, prima o poi arriverete a destinazione. Tuttavia la domanda sorge spontanea: quanto poi?

Supponendo, come avviene spesso in realtà, che ad ogni incrocio si dipanino 3 strade (oltre a quella da cui siete venuti) se disgraziatamente la ragazza si trova a solo 10 incroci di distanza dovrete testare circa 59.049 incroci e un numero maggiore di strade. Un compito decisamente eccessivo anche per il più motivato.

Dobbiamo trovare un alternativa. Appare evidente che abbiamo bisogno di un informazione che ci permetta di scartare le strade che sicuramente non ci portano a destinazione. Chiamiamo quindi la ragazza e scopriamo che è una nerd d’alta categoria. Ella infatti vole metterci alla prova. Invece di dirci la strada ci promette solo di dirci la distanza in linea retta che separa ogni incrocio che vogliamo da lei. È sufficiente? Si, e non solo troviamo una strada che ci conduce da lei ma troviamo la migliore.

LA RICERCA GOLOSA

La prima soluzione che ci viene in mente è semplice: fra tutti gli incroci che posso raggiungere da A scelgo quello che è più vicino alla ragazza e così via per ogni incrocio su cui vado a finire. Questo tipo di ricerca (che prende il nome di ricerca golosa) è sicuramente migliore della ricerca in ampiezza tuttavia ha due grossi problemi: non trova la strada più breve e, nel caso di grafo con cicli, può finire per ciclare all’infinito.

LA RICERCA A*

Scegliamo questa strategia: assegno a tutti gli incroci che posso raggiungere dall’incrocio in cui sono un numero N corrispondente alla somma della strada percorsa fino a quel punto più la distanza in linea retta che separa quell’incrocio dalla ragazza. A questo punto scelgo l’incrocio che ha il numero N più basso fra quelli che ho assegnato fin’ora. Questa ricerca prende il nome di A* ed è l’algoritmo di ricerca più efficiente  su un grafo pesato (come ad esempio una mappa stradale).

I punti a favore di A* sono fondamentalmente due: l’efficienza computazionale e il fatto che, in alcune condizioni, il percorso trovato è ottimo.

EURISTICHE AMMISSIBILI

Ma quali sono queste condizioni? Torniamo all’informazione che ci forniva la ragazza: la distanza in linea retta di ogni incrocio da lei. Questa prende il nome di funzione euristica. In parole povere è una funzione che esprime una stima della “distanza” dall’obiettivo. Bene, affinché la ricerca di A* sia ottima è necessario che la funzione euristica non sovrastimi mai la distanza reale dall’obiettivo! Quando questa condizione è soddisfatti si dice che la funzione euristica è ammissibile.

Nel nostro caso la funzione euristica soddisfa questa condizione in quanto la distanza in linea retta fra un incrocio e la ragazza non può mai essere maggiore della distanza reale (per definizione la retta è la distanza più breve fra due punti). La funzione è quindi ammissibile soluzione che troveremo sarà quindi ottima.

La non ammissibilità di una funzione non è però un limite stringente, spesso infatti trovare una funzione euristica ammissibile necessita di un quantitativo di calcoli troppo elevato che vanificherebbe i vantaggi di A*. In questi casi si può scegliere di usare una funzione non ammissibile ma di facile calcolo a patto di accontentarsi di una soluzione che potrebbe non essere ottimale.

Abbiamo imparato tanto in questa uscita. La ragazza al nostro arrivo sarà sicuramente soddisfatta.

Probabilmente fra tutti gli esempi di applicazioni dell’Intelligenza Artificiale la più semplice e famosa consiste sicuramente nel gioco 20q. Il gioco in questione funziona così: il giocatore pensa ad un oggetto o ad un animale e il marchingegno tenta di indovinare di cosa si tratta in meno di 20 domande a cui il giocatore può rispondere si o no. Potete trovare una versione online del gioco all’indirizzo http://www.20q.net/. Potrete constatare che in alcuni casi il programma sembra proprio leggervi nella mente con risultati quasi spaventosi.

La versione usata dal sito è piuttosto avanzata ed utilizza le reti neurali e permette quindi una gamma di riposte più vasto (c’è anche forse, probabilmente, a volte, ecc…). Il programma è inoltre in grado di apprendere mentre si gioca: ogni qual volta si gioca, o il programma si arrende richiedendo di inserire l’oggetto a cui si pensava, l’insieme di risposte appena date plasma la struttura dati interna del programma in modo tale che la prossima volta l’oggetto venga riconosciuto più velocemente. È un modello di apprendimento molto basilare ma che è analogo a quello umano percezione-previsione-modifica: il programma riceve dati percettivi (le risposte alle domande), formula un ipotesi (i tentativi di indovinare) e modifica la struttura dati in base all’esito della previsione.

Sarei curioso di sapere se il programma del sito ha qualche contromisura contro il problema del sovra-adattamento: questo tipo di problema affligge gran parte dei modelli decisionali, comprese le reti neurali, ed è causato da un eccessivo adattamento della rete a certi tipi di dati piuttosto che ad altri. Facciamo un esempio. Nel gioco 20q è molto più probabile che il giocatore pensi a cose “banali” come “gatto”, “cane”, “fiore” e simili piuttosto che a “antilope”, “spinterogeno” e “neutrino”. Questo significa che nel corso dell’esistenza del gioco il programma verrà addestrato alla perfezione a riconoscere cani e gatti mentre riceverà poche informazioni riguardo antilopi e neutrini. Possiamo quindi dire che “gatto” e “fiore” e le parole comuni facciano parte dell’insieme di addestramento di una rete. Bene, è possibile dimostrare che una rete sovra-adattata al suo insieme di addestramento indovina, in media, molto meno volte oggetti che non appartengono a tale insieme rispetto ad una rete che è solo parzialmente adattata.

Rimandiamo però questi approfondimenti sulle reti neurali. Il motivo per cui ho scritto questo articolo era di mostrare come sia possibile in una manciata di righe scrivere un programma che emuli in modo semplice il gioco di 20q. Per questa approssimazione consideriamo che sia possibile dare alle domande soltanto le risposte si o no.

Il metodo che vi mostrerò non utilizza nessuna tecnica propria dell’IA bensì dei semplicissimi alberi binari. Questi alberi binari li indicheremo come alberi decisionali binari. Nel nostro albero decisionale definaiamo:

• I nodi interni dell’albero sono domande.
• I nodi foglia dell’albero sono gli oggetti da indovinare.
• Il sotto-albero destro di un nodo corrisponde al caso in cui la risposta alla domanda sia si.
• Il sotto-albero sinistro di un nodo corrisponde al caso in cui la risposta alla domanda sia no.

L’algoritmo del gioco consiste in una cosa del tipo:

• Il programma formula la prima domanda che trova (cominciando con il nodo radice).
• Se non c’è più nessuna domanda il programma si arrende e chiede al giocatore di inserire 1) l’oggetto a cui stava pensando. 2) una domanda che rappresenta l’oggetto 3) la risposta a questa domanda.
• Il programma aggiunge questa domanda e la relativa risposta al sotto albero in cui si era fermato (oppure come nodo radice se l’albero era vuoto).
• Se invece la domanda c’è il programma formula la domanda e scende nel sotto-albero relativo alla risposta.
• Il programma ricomincia dal punto 1.

Tutto qui. Tale algoritmo è effettivamente molto grezzo e sono possibili un gran numero di migliorie (ad esempio usare dei modelli di albero più “elastici” per evitare alberi troppo sbilanciati) ma svolge decentemente il proprio lavoro. Dopo che l’avete fatto girare per qualche tempo vedrete che inizierà ad imparare e ad indovinare un discreto numero di parole. Ovviamente potete partire da un albero vuoto oppure pre-costruire un albero di base con alcune domande comuni.

Un altra cosa che può farci capire questo semplice programma è una considerazione che mi ha fatto notare un gentile commentatore: la capacità degli algoritmi di AI non dipende dalla dimensione del programma ovvero dal suo numero di righe di codice allo stesso modo di come le capacità celebrali umane non dipendono dalla dimensione del cervello (una balena ha il cervello molto più voluminoso di un essere umano eppure fa molte meno cose). Le capacità cognitive di un programma dipendono solamente dalle relazioni che si auto-generano fra le strutture dati del programma (nel nostro caso tali relazioni sono i collegamenti ad albero fra i nodi).

Se qualcuno avesse voglia di creare questo programmino usando il minor numero di righe possibili sarei felice di pubblicarlo. Inoltre potreste anche usarlo per sbalordire amici, parenti e vicini di casa! XD

Alla prossima!

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.

Effettuare il tuning di un modulo C.

L’efficenza di un algoritmo e di un programma va affrotata in due passi: un analisi teorica dell’algoritmo e una analisi “on the road” in cui l’algoritmo va implementato e testato sulle varie architetture reali.

Ovviamente, come abbiamo avuto modo di vedere, non c’è linguaggio che possa vantare le capacità prestazionali del C, anche senza contare le capacità di interfacciarsi direttamente a basso livello con innesti di codice assembly grazie al costrutto _asm_.

Ma come tutti gli strumenti potenti vanno saputi utilizzare, molto spesso differenze impercettibili e che pensiamo irrilevanti si ripercuotono in maniera catastrofica sul nostro software. Ad esempio ho avuto modo di vedere algoritmi in cui la sola variazione di due parametri strutturali faceva passare il tempo di esecuzione da 2 minuti a 11 giorni.

E’ quindi importante identificare, in un software, quali sono le funzioni e le procedure che occupano più tempo, e quale è il loro peso nel tempo complessivo di esecuzione.

A venirci incontro è proprio GProf.

GProf è un tool che permette di interpretare con statistiche avanzate sui tempi di esecuzioni delle singole funzioni il file di profiling generato dagli eseguibili compilati con il parametro -pg.

Ma andiamo con ordine. Per utilizzare GProf per prima cosa prendiamo il nostro codice C e compiliamolo come consueto ma aggiungendo il parametro -pg.

gcc prova.c -o prova -pg

Dopo aver compilato correttamente il file non ci resta che eseguirlo. Una volta terminato ci accorgeremo che nella cartella dell’eseguibile è stato creato un file chiamato gmon.out.

Ora per leggere il report dettagliato non ci resta che dare il comando:

gprof prova | less

I primi dati ce potremo consultare sono i tempi di esecuzioni delle singole funzioni del programma ordinate in ordine decrescente in base alla percentuale di tempo di esecuzione. Ma non solo, possiamo vedere anche quante volte una data funzione viene chiamata. Come ad esempio:

% cumulative  self              self     total
 time seconds  seconds  calls s/call s/call name
43.32   46.03  46.03 339952989  0.00  0.00 CompareNodes(Node *,Node *)
25.06   72.66  26.63    55000   0.00  0.00 getNode(char *,NodeListNode *&)
16.80   90.51  17.85 339433374  0.00  0.00 CompareEdges(Edge *,AnnotatedEdge *)
12.70  104.01  13.50    51987   0.00  0.00 addAnnotatedEdge(AnnotatedGraph *,Edge *)
 1.98  106.11   2.10    51987   0.00  0.00 addEdge(Graph *,Node *,Node *)
 0.07  106.18   0.07        1   0.07  0.07 FindTreshold(AnnotatedEdge *,int)
 0.06  106.24   0.06        1   0.06 28.79 getGraphFromFile(char *,NodeListNode *&,Config *)
 0.02  106.26   0.02        1   0.02 77.40 summarize(GraphListNode *,Config *)
 0.00  106.26   0.00    55000   0.00  0.00 FixName(char *)

Un altro modo che abbiamo per consultare il file di profiling è usando alcuni tool grafici, fra i quali vi cito KProf per KDE, con il quale potrete accedere alle stesse informazioni grazie all’interfaccia grafica spartana ma completa.

Una volta che abbiamo a disposizione questi dati non ci resta che individuare le funzioni anomale, apportare modifiche, ricompilare e vedere le eventuali variazioni in termini di tempo di esecuzione… sperando siano positive!

Fate alcuni esperimenti e vedrete che GProf sarà il vostro migliore amico nel debellare il virus dell’inefficenza!

LINK UTILI:

• Optimizing C/C++ programs using the GProf profiler [ENG]
• GNU prof Homepage [ENG]

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.

Per capire la ricorsione bisogna innanzitutto capire la ricorsione...

Ora conosciamo sufficientemente la struttura della memoria e i principi del suo funzionamento. Per spiegare lo stack, in particolare, ho dovuto fare richiamo alle funzioni.

Le funzioni sono un argomento fondamentale della programmazione e alcuni processori le implementano addirittura a livello di assembly.

Il concetto di funzione è molto semplice. Una funzione può essere vista come una “macchina” che riceve in pasto dei dati, li elabora e a volte restituisce un risultato.

La funzione “+” è una funzione che prende come dati due numeri (parametri), gli somma (corpo della funzione) e restituisce il risultato (valore di ritorno). La funzione print (presente in molti linguaggi) prende come dati una stringa e gli elabora stampandoli sullo schermo.

Le funzioni sono definibili dall’utente e tutti i linguaggi permettono di definire funzioni.

Ma come funziona una funzione ( )?

Con lo stack. Quando chiamiamo una funzione il computer crea un nuovo elemento in cima allo stack chiamato record di attivazione che contiene la copia dei dati passati per parametro, il puntatore all’ultima istruzione eseguita nella funzione “madre” e lo spazio per il valore di ritorno.

Quasi tutte le funzioni tradizionali sono funzioni iterative ovvero che ricavano la loro soluzione solo mediante i dati e altre funzioni.

Questo meccanismo dello stack però permette di implementare un altro strumento molto potente: la ricorsione.

La ricorsione consiste nell’usare una funzione (con parametri più piccoli) all’interno della stessa funzione. Consiste cioè nel risolvere un problema risolvendone uno di taglia minore.

Per esempio potremo pensare ad una versione ricorsiva della moltiplicazione:

def moltiplicazione(x,y) :
    if y == 1 : return x
    return x + moltiplicazione(y-1) :

Come si vede si risolve x*y risolvendo x*(y-1) + x … e cosi via.

Dall’esempio vediamo che una funzione ricorsiva si divide in:

• Uno o più CASI BASE: ovvero le condizioni immediate, la cui soluzione non necessita di usare la ricorsione. (nell’esempio è il caso x*1 = x)
• Uno o più CASI RICORSIVI: ovvero i casi in cui si usa la ricorsione.

Ovviamente i casi base sono necessari per far terminare la ricorsione. (Una ricorsione infinita causa uno stack overflow ovvero lo stack si mangia tutta la memoria a disposizione).

Le soluzioni ricorsive sono molto eleganti ma hanno lo svantaggio che la pila dei record di attivazione e la loro creazione “mangia” risorse non necessarie esclusivamente alla risoluzione del problema. Quindi nei casi di programmi che necessitano di alte prestazioni tutti gli algoritmi ricorsivi vengono convertiti in iterativi.

Ma è sempre possibile?

Si. Dato un algoritmo ricorsivo è SEMPRE possibile scrivere il suo corrispettivo iterativo.

Il caso più semplice è quello in cui la ricorsione è l’ultima operazione della funzione. Questi casi vengono chiamati tail recursion e molti compilatori sono in grado di individuarli e convertirli in automatico nella loro versione iterativa.

Casi più complessi invece vengono convertiti usando una pila artificiale creata dal programmatore che essendo fatta ad-hoc per l’algoritmo contiene solo le informazioni necessarie e quindi è molto più efficente!

Foto di un programma che usa algoritmi scadenti.

Abbiamo visto cos’è un algoritmo, come è suddiviso e come lo si rappresenta astrattamente in fase di “progetto”.

Ora affronteremo il come progettarlo e in particolare il metodo del Dividi et Impera.

La progettazione di un algoritmo è la fase più delicata del processo di programmazione. Spesso scelte che sembrano ininfluenti nella nostra mente si tramutano in barriere computazionali invalicabili (cosa che appare manifesta se si combatte con il Progetto Eulero).

Possiamo distinguere 3 fasi:

1) SCOMPOSIZIONE IN SOTTO PROBLEMI

In questa fase abbiamo nella nostra testa solamente l’obbiettivo che ci prefiggiamo (risultato) e i punti di partenza (dati in ingresso). Per esempio abbiamo l’obbiettivo di fare la spesa nel minor tempo possibile avendo come dati in ingresso la posizione dei supermercati della città.

La prima cosa da fare a questo punto è trovare a grandi linee i passi che ci portano dalla partenza all’obbiettivo. Nel nostro esempio sappiamo che la soluzione consiste nel:

1. Trovare la strada più breve per arrivare ad un supermercato.
2. Andare a fare la spesa.
3. Trovare la strada più breve per tornare a casa.

2) RISOLUZIONE DEI SOTTO-PROBLEMI

Trovati i sotto problemi del nostro problema principale dobbiamo risolvere i sotto-problemi (i quali di solito sono più semplici del problema di partenza) tenendo conto che abbiamo a disposizione solo tre elementi:

1. Istruzioni (le istruzioni da eseguire).
2. Controlli su condizioni (corrisponde all’italiano se…).
3. Salti (per saltare ad un istruzione specifica).

Qui non c’è un metodo universale. Bisogna lavorare di intuito suddividendo, se necesarrio, il sotto-problema in sotto-sotto-problemi, se necessario fino al punto in cui i sotto-sotto-sotto-…..-sotto-problemi non diventino le istruzioni base di cui disponiamo.

3) UNIONE DEI RISULTATI

Questa fase non è banale come sembra. Per ricostruire il problema principale sembra ovvio che vadano messi in fila i risultati dei sotto-problemi. Invece no. Qui è il punto (non l’unico ma uno dei principali) in cui entra in gioco l’efficienza.

Per tornare all’esempio della spesa ci rendiamo conto. Che i sotto-problemi (1) e (2) in realtà fanno la stessa cosa: la strada più breve all’andata, con buona possibilità, sarà anche la più breve al ritorno.

Quindi perchè calcolarla due volte? Basta salvare da qualche parte il risultato del problema (1) e riutilizzarlo in (3) senza pagare due volte il costo (in termini di calcolo) dell’elaborazione del percorso.

In questo esempio sembra ovvio ma vi assicuro che non è cosi. Spesso quando si programma si tende a andare a risparmio sulle variabili (forse per non sforzarsi a trovare un nome) e quindi a volte per usare un valore si applica più volte la funzione che lo genera. Ma spesso questo appesantisce enormemente il lavoro e l’efficienza.

Sul costo e la complessità di un algoritmo torneremo in seguito perchè è un argomento interessante e utile.

Abbiamo quindi definito queste fasi: SCOMPOSIZIONE-RISOLUZIONE-UNIONE. Questo principio prende il nome di Dividi et Impera ed oltre ad avere il vantaggio di aiutare nella “creazione” rende il software modulare il che comporta:

1. Maggiore capacità di manutenzione e individuazione degli errori.
2. Possibilità di riutilizzare la stessa soluzione di un sotto-problema di un algoritmo in un altro algoritmo (Per esempio il problema di trovare la strada più breve per fare la spesa lo si può riutilizzare nel trovare la strada più breve per un viaggio).

Bene. Poichè per approfondire maggiormente alcuni concetti non posso trascendere dall’informatica, dobbiamo abbandonare per un po gli algoritmi per introdurre concetti di programmazione dei calcolatori vera e propria.

No... forse non è questo un algo-ritmo...

Nella scorsa lezione abbiamo visto che cosa è la programmazione e abbiamo notato che si può semplificare nella creazione di algoritmi.

L’astrazione da ogni linguaggio ci permette di dimenticarci per il momento le difficoltà implementative di ogni algoritmo e concentrarci solo sulla sua essenza.

Partiamo quindi dalla struttura di algoritmi veramente semplici.

Il più semplice tipo di algoritmo consiste in una semplice lista di istruzioni. Se per esempio vogliamo scrivere l’algoritmo per fare la pasta potremo scrivere:

1. Metti l’acqua a bollire.
2. Aspetta che l’acqua bolla.
3. Mettere la pasta.
4. Aspetta che sia cotta.
5. Scola la pasta.

Questo è un algoritmo aciclico (ovvero privo di salti all’indietro, in poche parole di istruzioni ripetute più volte) e a flusso unico (ovvero tutte le istruzioni sono eseguite almeno una volta). E’ il modello di algoritmo più semplice.

Al lettore attento non sarà sfuggito però che ogni istruzione potrebbe considerarsi a sua volta come un algoritmo. Per esempio la (1) potrebbe diventare:

1. Prendi la pentola.
2. Riempila d’acqua.
3. Accendi il fornello.
4. Metti la pentola sul fornello.

E via dicendo. A sua volta anche “prendi la pentola” potrebbe essere scomposto.

Ma fino a che punto dobbiamo espandere le operazioni di un algoritmo?

La risposta in verità dipende dal linguaggio che si userà per realizzare l’algoritmo. Se vogliamo eseguirlo in assembly dovremmo espanderlo ai massimi livelli mentre se vogliamo farlo in Java avremo bisogno di un minore dettaglio.

E’ buona norma però, quando si scrivono algoritmi, partire sempre da un livello di dettaglio basso e scomporre via via i sotto-problemi risultanti in altri sotto-algoritmi. Un po come abbiamo fatto per l’esempio della pasta. Questa segnatela perché all’atto pratico è una delle cose più potenti che un programmatore possa fare: la modularizzazione (di cui parleremo in seguito)

L’istruzione (2) “Aspetta che l’acqua bolla.” scomposta rivela proprietà che non avevamo visto nell’algoritmo generale. Scomposto infatti assume questa forma:

1. Guarda l’acqua nella pentola.
2. Se bolle termina, altrimenti torna a (1).

Come si nota questo è un algoritmo ciclico (dei più semplici pergiunta) in quanto presenta una condizione che ci fa tornare indietro ad un istruzione precedente. Questo è quindi un ciclo.

Quindi il nostro algoritmo aciclico di partenza in realtà nasconde un sotto-algorimto ciclico.

Ora ci chiediamo qual’è il metodo più efficace per rappresentare un algoritmo? Il metodo forse più conosciuto è quello dei diagrammi di flusso (per approfondire vai qui)

Il diagramma di flusso del calcolo del fattoriale. Il calcolo del fattoriale è un algoritmo ciclico e a flusso multiplo.

Il diagramma di flusso è quindi una rappresentazione per via grafica molto evidente di quello che fa l’algoritmo. Lo svantaggio che lo rende inapplicabile in quasi tutti i casi pratici è che è inadatto per algoritmi vasti e complessi in quanto stare dietro a frecce e blocchi sparse per una superficie troppo vasta più che aiutare disorienta.

A questo punto ci viene in aiuto lo pseudo-codice.

Lo pseudo-codice in realtà non è molto dissimile dalla lista di istruzioni che ho usato per rappresentare l’algoritmo della pasta. In poche parole è un algoritmo espresso in linguaggio naturale impostato in modo tale da somigliare a un listato di codice.

Non c’è una tecnica universale per lo pseudo-codice, ognuno è libero di trovare il suo stile a patto che il risultato sia comprensibile e chiaro ai più. Per esempio (2) “Aspetta che l’acqua bolla.” diventerebbe una cosa del tipo:

algoritmo AspettaAcquaBolle() :
Finchè <l’acqua NON bolle> :
<Guarda L’acqua>

Mentre l’algoritmo del fattoriale diventerebbe:

algoritmo Fattoriale(Numero Intero N) :
Se N=0 :
restituisci 1
altrimenti :
restituisci N * Fattoriale(N-1)

Come vedete il risultato è facilmente interpretabile e la struttura permette una conversione piuttosto semplice in un linguaggio di programmazione vero e proprio. Si tratta cioè di tradurre riga per riga lo pseudo-codice in codice.

Nella prossima lezione parleremo ancora degli algoritmi introducendo concetti un po più complessi che per ora vedremo solo in modo superficiale ma che, volendo approfondirò più avanti.