L'algoritmo Thomas è il modo più veloce per risolvere un sistema lineare tridiagonale rado simmetrico dominante dominante

Mi chiedo se l'algoritmo di Thomas sia il modo più rapido (di fatto?) Di risolvere un sistema tridiagonale sparsa in modo diagonale in termini di complessità algoritmica (non cercando pacchetti di implementazione come LAPACK ecc.). So che sia l'algoritmo di Thomas che il multigrid sono complessità, ma forse il fattore costante per multigrid è inferiore? Non mi sembra che il multigrid possa essere più veloce ma non sono positivo. $O(n)$

Nota: sto considerando il caso in cui le matrici sono molto grandi. Sono accettabili metodi diretti o iterativi.

— Giacomo
fonte

Risposte:

$8N$

$O(N)$

— Aurelio
fonte

Grazie. Mi rendo conto che i metodi iterativi non sono esatti. Avrei dovuto specificare una tolleranza molto piccola (diciamo 10 ^ -15) e trattarla come "esatta" ai fini del confronto.

— James,

@ user2697246 bene, hai chiesto "dimostrabilmente" il più veloce. L'esatto tasso di convergenza per multigrid (o qualsiasi schema iterativo) dipenderà sempre dalla soluzione stessa e dall'ipotesi iniziale: una soluzione lineare sarà effettivamente risolta esattamente in un passaggio, mentre qualcosa di più oscillatorio richiederà più operazioni. Thomas ha un conteggio esatto e fisso per tutti i casi. In pratica, non batterai mai Thomas per aver risolto (in serie) un sistema tridiagonale per un caso non banale.

— Aurelio,

@Aurelius L'algoritmo di Thomas può essere parallelizzato? Altrimenti, questo è uno dei maggiori vantaggi di multigrid!

— Nick Alger,

O (N l o g N)

$O(N log N)$

N

$N$

Una correzione, l'algoritmo Thomas richiede operazioni 8N, non 9N. Inoltre, cosa intendi per "multigrid ... avere una soluzione lineare"? Tutti i sistemi in esame qui sono lineari.

— Doug Lipinski,

La risposta breve è che l'algoritmo di Thomas sarà più veloce di qualsiasi schema iterativo per quasi tutti i casi. L'eccezione potrebbe forse essere l'applicazione di una singola iterazione di uno schema iterativo molto semplice come Gauss-Seidel, ma è altamente improbabile che ciò fornisca una soluzione accettabile. Inoltre, questo sta ignorando i problemi di elaborazione parallela.

$\mathcal O(n)$ $\mathcal O(n)$

$5N$ $3N$ $3N-2$ $2N-2$

— Doug Lipinski
fonte

"Multigrid è una scelta particolarmente scadente nel caso di una matrice tri-diagonale perché sebbene il multigrid sia O (n), la costante è piuttosto grande." Lo penso anche io, ma googling ha sollevato una riga nel libro Multigrid di Trottenburg che afferma una costante di 0,1-0,2, dichiarata senza prove. Non credo di crederci.

— Aurelio,

@Aurelius Interessante. Questo è chiaramente impossibile nel caso generale poiché ci sono voci 3N in una matrice tridiagonale. Se il costo è ~ 0,1 * N, ciò significa che non si opera nemmeno sulla maggior parte delle voci.

— Doug Lipinski,

Sì, siamo sulla stessa pagina; la semplice valutazione di uno stencil a 3 punti richiede operazioni 3N. Stavo solo scremando, quindi forse ho frainteso del tutto l'affermazione, ma puoi vederlo da solo nell'estratto di Google Libri.

— Aurelio,

La citazione completa (pag. 21) è "L'efficienza in senso pratico significa che le costanti di proporzionalità in questa affermazione O (N) sono piccole o moderate. Questo è il caso del multigrid: se progettato bene, i fattori di convergenza indotti da h possono essere reso molto piccolo (nell'intervallo di 0,1-0,2 o anche meno) e anche il conteggio delle operazioni per sconosciuto per fase di iterazione è piccolo. " Lo 0,1-0,2 si riferisce alla riduzione residua per ciascun ciclo di multigrid. La costante su O (N) sarebbe dell'ordine di 1,5-2,0 volte la matrice moltiplicare per ciclo (per un totale di una dozzina o due cicli).

— Godric Seer,

Ah, grazie @GodricSeer, ha più senso.

— Aurelio,

I loop multigrid anche su single core sono vettorializzabili dall'ottimizzatore. Quindi, mentre i conteggi delle operazioni possono aiutare, non dovremmo dimenticare che anche nel mondo seriale i processori hanno un parallelismo vettoriale e quindi il time-to-solution potrebbe non essere esattamente ciò che prevediamo dall'analisi dei costi.

— Hasbestein
fonte