Discussione:Merge sort

message: Ricordo a tutti che le implementazioni in specifici linguaggi vanno messe su Wikibooks, come da decisione della comunità. Il link a wikibooks è in fondo alla voce, nella sezione Altri progetti. Grazie. --Giuseppe (msg) 16:43, 27 gen 2010 (CET)
thread_title:  Implementazioni 

message: Scrivi che la complessità computazionale è costante,ma invece è uguale a n nel caso migliore , e nlogn nel caso peggiore.
Perchè durante la procedura di merge, supponiamo di avere 2 array ognuno di dimensione n/2, se il primo array contiene elementi tutti quanti più piccoli del primo array, allora bisogna effettuare n/2 confronti, e l' array riunito avrà nella prima metà tutti gli elementi del primo sub-array, ma gli elementi della seconda metà si copiano uguali a quelli del secondo sub-aray, senza stare a confrontarli.
Nel caso peggiore cioè un array del tipo 1 3 5 7 2 4 6 allora si che ha complessità uguale a nlogn.Ma non è un costo costante. 
:Ho annullato la modifica, era corretto prima. Il fatto che la complessità dell'algoritmo sia Θ(n log n) per qualunque distribuzione degli input dipende da due fatti:
:# La complessita della procedura merge è Θ(n).
:# La profondità della ricorsione della procedura mergesort è Θ(log n).
:
:Ad esempio, se l'array in input fosse 1 2 3 4 5 6 7 8, l'albero di ricorsione sarebbe (elenco livello per livello):
:#mergesort([1, 2, 3, 4, 5, 6, 7, 8])
:#mergesort([1, 2, 3, 4]) e mergesort([5, 6, 7, 8]), con 1 merge che effettua ~4 confronti
:#mergesort([1, 2]) mergesort([3, 4]), mergesort([5, 6]), mergesort([7, 8]), con 2 merge che effettuano ciascuno ~2 confronti
:#mergesort([1]), mergesort([2]), mergesort([3]), mergesort([4]), mergesort([5]), mergesort([6]), mergesort([7]), mergesort([8]), con 4 merge che effettuano ciascuno ~1 confronto.
:Come vedi, a parte la chiamata iniziale, ci sono esettamente 3 = log 8 livelli, e ad ogni livello il numero totale di confronti è sempre Θ(n). Ciao, Salvatore Ingala (conversami) 09:21, 23 ott 2011 (CEST)
replies: text: Mi scuso per non aver risposto prima, ma in questi giorni sono stato impegnato e la cosa mi era totalmente passata di mente; soprassiedo sul tuo insulto, che ho rimosso dalla pagina. Ho approfondito un po' la faccenda, e il tuo ragionamento è corretto; il problema è che tu hai fatto questo ragionamento senza considerare l'implementazione in pseudocodice dell'algoritmo merge presentata nella voce, mentre io mi rifacevo a quella; la merge si può implementare in vari modi, e il modo descritto nella voce non è in grado di sfruttare il caso fortunato dell'array totalmente ordinato. Basta notare che la procedura merge si conclude con un "for k ← left to right do...", che da solo ha già un costo uguale a Θ(n). Un'implementazione più intelligente (come quella che c'è nell'analoga voce su en:wiki) avrebbe la proprietà che tu dici. Modifico il tuo testo per chiarire questo fatto, anche se sarebbe ancora meglio approfondire tutta la voce, aggiungendo dei cenni alle diverse implementazioni possibili; il testo su en.wiki potrebbe essere un'ottima base, se ti va di lavorarci. Ciao, Salvatore Ingala (conversami) 20:26, 29 ott 2011 (CEST)
thread_title:  Complessità computazionale del mergesort 

message: Ho rivisto un po' la voce. Sostanzialmente, ho
* sistemato la formattazione del primo esempio e tolto il secondo (non è molto chiaro, soprattutto perché la differenza sostanziale tra top-down e bottom-up è 'sottintesa' nel prmo esempio, e i due esempi sembravano almeno a una prima lettura uguali)
* cambiato\adattato la spiegazione del funzionamento (prendendo _molto_ spunto da en:wiki)
* messo un po' di formattazione nello pseudocodice (parole chiave in grassetto, tolto le parentesi, usato and invece che && come operatore booleano)
* sistemate\toccate alcune cose qua e la' --80.116.54.220 (msg) 23:50, 22 dic 2011 (CET)
thread_title:  Revisione voce