In che modo il passaggio di divisione in Unisci ordinamento ha una complessità a tempo costante?

1

Sono altamente confuso nel calcolare la complessità temporale di un algoritmo di merge sort. In particolare sulla fase di divisione. Nella fase di divisione dobbiamo calcolare il punto medio di "n" cioè "q = n / 2".

Come ci vorrà tempo costante. Se supponiamo che la divisione sia un'operazione elementare e impieghi molto meno tempo, allora dovremmo includere anche il tempo impiegato dalla divisione.

Supponiamo di dover dividere una quantità molto grande di tempo quindi deve essere considerato mentre si calcola la complessità temporale. Secondo me il numero di divisioni dipende da "n", ad esempio il punto medio di calcolo dipende dalla dimensione dell'array "n".

Ad esempio,

if n = 2

Numero di divisioni richieste = 1

se n = 4

Numero di divisioni richieste = 3

if n = 8

Numero di divisioni richieste = 7

se n = 16

Numero di divisioni richieste = 15 e così via ....

Secondo me,

Se Definisci in modo ricorsivo: -

Numero di Divide necessario per "n" (input array length = n) < = 1 + Numero di divisioni necessarie per (n-1). {quando n = 0 Numero di divisioni = 0 quando n = 1 Number of divide = 0}

In alternativa ..........

Numero di divisioni necessarie per "n" (lunghezza dell'array input = n) < = (somma di 2 ^ i da 0 a n-1) - (2 ^ n)

Quindi, dipende da "n". Quindi, come possiamo prenderlo come un tempo costante ????

    
posta Bhaskar 26.09.2016 - 14:54
fonte

4 risposte

1

Sono felice che tu abbia avuto il tempo di provare a capire questa apparente discrepanza. Hai ragione che dobbiamo tenere conto delle divisioni e che per questo algoritmo abbiamo ~n divisioni. In generale, se dividiamo numeri ragionevolmente piccoli (quelli che rientrano in un lungo), contiamo che le singole operazioni di divisione siano effettivamente O(1) , quindi abbiamo O(n) divisioni.

Ciò che ti manca è che non ha molta importanza, perché abbiamo già un'operazione O(n) nel mix: l'unione. In questo caso particolare, è per questo che l'aggiunta delle divisioni non modifica la complessità complessiva da O(n log n) . Contabilizzare le divisioni lo cambierebbe in O(2n log n) e le costanti verranno scomposte.

    
risposta data 26.09.2016 - 19:23
fonte
2

If we assume that divide is an elementary operation and take very less time, then also we should include the time taken by divide

Big O non misura realmente la durata di una singola operazione. Piuttosto, misura quanto bene un algoritmo si ridimensiona man mano che aumenti il numero di singole operazioni.

Considera questo grafico:

L'asseorizzontalerappresentan.L'asseverticalerappresentailtempototaledicalcolo.Sinotiche,perpiccolivaloridin,glialgoritmiO(n²)eO(n³)possonoeffettivamentefunzionaremegliodellalorocontroparteO(1).Questoperché,inquestoipoteticoesempio,lasingolaoperazionenell'algoritmoO(1)èpiùcostosadellesingoleoperazionineglialgoritmiO(n²)eO(n³).

Prenderòinconsiderazioneche"la fase di divisione richiede tempo costante" per essere piuttosto ovvia, ma la ragione per cui è un tempo costante è perché è un singolo calcolo.

    
risposta data 26.09.2016 - 17:06
fonte
0

A questo punto, tutto l'autore dice che un passo di divisione singolo costa O (1). L'autore non sta facendo un reclamo su come eseguire 3 dividi passaggi o 1000000 dividi passaggi.

    
risposta data 27.09.2016 - 17:21
fonte
0

Il numero di volte in cui compare è il motivo della complessità temporale per la maggior parte degli algoritmi di ordinamento. In qualsiasi algoritmi di divisione e conquista , il numero massimo di volte in cui divide è n -1 che è più piccolo di n log ( n ), quindi è trascurabile.

    
risposta data 28.09.2016 - 06:45
fonte

Leggi altre domande sui tag