Come migliorare l'efficienza con la programmazione funzionale?

Di recente ho seguito la guida Learn You a Haskell for Great Good e come pratica volevo risolvere il problema del Project Euler 5 con esso, che specifica:

Qual è il numero positivo più piccolo che è uniformemente divisibile per tutti i numeri da 1 a 20?

Ho deciso di scrivere prima una funzione per determinare se un determinato numero è divisibile per questi numeri:

divisable x = all (\y -> x `mod` y == 0)[1..20]

Quindi ho calcolato il più piccolo usando head:

sm = head [x | x <- [1..], divisable x]

E infine ha scritto la riga per visualizzare il risultato:

main = putStrLn $ show $ sm

Sfortunatamente, il completamento ha richiesto circa 30 secondi. Fare la stessa cosa con i numeri da 1 a 10 produce un risultato quasi immediatamente, ma anche in questo caso il risultato è molto più piccolo della soluzione da 1 a 20.

L'ho risolto in precedenza in C e lì il risultato per 1 a 20 è stato anche calcolato quasi istantaneamente. Questo mi porta a credere che sto fraintendendo come interpretare questo problema per Haskell. Ho cercato le soluzioni degli altri e ho trovato questo:

main = putStrLn $ show $ foldl1 lcm [1..20]

Abbastanza giusto, questo utilizza una funzione integrata, ma perché il risultato finale è molto più lento quando lo fai da solo? I tutorial là fuori ti spiegano come usare Haskell, ma non vedo molto aiuto nel trasformare gli algoritmi in codice veloce.

Per prima cosa devi assicurarti di avere un binario ottimizzato, prima di pensare che la lingua sia il problema. Leggi il capitolo Profilazione e ottimizzazione in Real Wolrd Haskell. Vale la pena notare che nella maggior parte dei casi la natura di alto livello della lingua ti costa almeno alcune delle prestazioni.

Tuttavia, si noti che l'altra soluzione non è più veloce perché utilizza una funzione integrata, ma semplicemente perché utilizza un algoritmo molto più veloce : per trovare il minimo comune multiplo di un insieme di numeri devi solo trovare alcuni GCD. Confronta questo con la tua soluzione, che scorre attraverso tutti i numeri da 1 a foldl lcm [1..20]. Se provi con 30, la differenza tra i tempi di autonomia sarà ancora maggiore.

Dai un'occhiata alle complessità: il tuo algoritmo ha O(ans*N)runtime, dov'è ansla risposta ed Nè il numero fino al quale stai verificando la divisibilità (20 nel tuo caso).
L'altro algoritmo esegue i Ntempi lcm, tuttavia lcm(a,b) = a*b/gcd(a,b), e GCD ha complessità O(log(max(a,b))). Pertanto il secondo algoritmo ha complessità O(N*log(ans)). Puoi giudicare da solo quale è più veloce.

Quindi, per riassumere: il
tuo problema è il tuo algoritmo, non la lingua.

Nota che ci sono linguaggi specializzati che sono sia funzionali che focalizzati su programmi matematici pesanti, come Mathematica, che per problemi incentrati sulla matematica è probabilmente più veloce di qualsiasi altra cosa. Ha una libreria di funzioni molto ottimizzata e supporta il paradigma funzionale (è vero che supporta anche la programmazione imperativa).

Il mio primo pensiero è stato che solo i numeri divisibili per tutti i numeri primi <= 20 saranno divisibili per tutti i numeri inferiori a 20. Quindi è necessario considerare solo numeri multipli di 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 . Tale soluzione controlla 1 / 9.699.690 di quanti numeri si avvicina alla forza bruta. Ma la tua soluzione fast-Haskell fa di meglio.

Se capisco la soluzione "veloce di Haskell", usa foldl1 per applicare la funzione mcm (il minimo comune multiplo) all'elenco di numeri da 1 a 20. Quindi applicherebbe lcm 1 2, producendo 2. Quindi lcm 2 3 cedendo 6 Quindi mcm 6 4 cedendo 12, e così via. In questo modo, la funzione mcm viene chiamata solo 19 volte per dare la tua risposta. Nella notazione Big O, si tratta delle operazioni O (n-1) per arrivare a una soluzione.

La tua soluzione slow Haskell passa attraverso i numeri 1-20 per ogni numero compreso tra 1 e la tua soluzione. Se chiamiamo soluzione s, allora la soluzione slow Haskell esegue operazioni O (s * n). Sappiamo già che s è oltre 9 milioni, quindi questo probabilmente spiega la lentezza. Anche se tutte le scorciatoie e ottengono una media a metà dell'elenco dei numeri 1-20, è comunque solo O (s * n / 2).

chiamata head non ti salva dal fare questi calcoli, devono essere fatti per calcolare la prima soluzione.

Grazie, questa è stata una domanda interessante. Ha davvero ampliato la mia conoscenza di Haskell. Non sarei in grado di rispondere affatto se non avessi studiato algoritmi lo scorso autunno.

Inizialmente non avevo intenzione di scrivere una risposta. Ma mi è stato detto dopo che un altro utente ha fatto la strana affermazione che semplicemente moltiplicare i primi primi due era più costoso dal punto di vista computazionale quindi applicare ripetutamentelcm . Quindi ecco i due algoritmi e alcuni benchmark:

Il mio algoritmo:

Algoritmo di prima generazione, che mi dà un elenco infinito di numeri primi.

isPrime :: Int -> Bool
isPrime 1 = False
isPrime n = all ((/= 0) . mod n) (takeWhile ((<= n) . (^ 2)) primes)

toPrime :: Int -> Int
toPrime n 
    | isPrime n = n 
    | otherwise = toPrime (n + 1)

primes :: [Int]
primes = 2 : map (toPrime . (+ 1)) primes

Ora usando quell'elenco principale per calcolare il risultato per alcuni N:

solvePrime :: Integer -> Integer
solvePrime n = foldl' (*) 1 $ takeWhile (<= n) (fromIntegral <$> primes)

Ora l'altro algoritmo basato su mcm, che è certamente abbastanza conciso, principalmente perché ho implementato la generazione primaria da zero (e non ho usato l'algoritmo di comprensione dell'elenco super conciso a causa delle sue scarse prestazioni) mentre è lcmstato semplicemente importato da Prelude.

solveLcm :: Integer -> Integer
solveLcm n = foldl' (flip lcm) 1 [2 .. n]
-- Much slower without `flip` on `lcm`

Ora per i benchmark, il codice che ho usato per ciascuno era semplice: ( -prof -fprof-auto -O2quindi +RTS -p)

main :: IO ()
main = print $ solvePrime n
-- OR
main = print $ solveLcm n

Per n = 100,000, solvePrime:

total time = 0.04 secs
total alloc = 108,327,328 bytes

vs solveLcm:

total time = 0.12 secs
total alloc = 117,842,152 bytes

Per n = 1,000,000, solvePrime:

total time = 1.21 secs
total alloc = 8,846,768,456 bytes

vs solveLcm:

total time = 9.10 secs
total alloc = 8,963,508,416 bytes

Per n = 3,000,000, solvePrime:

total time = 8.99 secs
total alloc = 74,790,070,088 bytes

vs solveLcm:

total time = 86.42 secs
total alloc = 75,145,302,416 bytes

Penso che i risultati parlino da soli.

Il profiler indica che la generazione principale occupa una percentuale sempre più piccola del tempo di esecuzione man mano che naumenta. Quindi non è il collo di bottiglia, quindi possiamo ignorarlo per ora.

Ciò significa che stiamo davvero confrontando la chiamata in lcmcui un argomento va da 1 a n, e l'altro va geometricamente da 1 a ans. Chiamare *con la stessa situazione e l'ulteriore vantaggio di riuscire a saltare tutti i numeri non primi (asintoticamente gratuitamente, a causa della natura più costosa di *).

Ed è risaputo che *è più veloce di lcm, poiché lcmrichiede ripetute applicazioni di mod, ed modè asintoticamente più lento ( O(n^2)vs~O(n^1.5) ).

Quindi i risultati di cui sopra e la breve analisi dell'algoritmo dovrebbero rendere molto ovvio quale algoritmo è più veloce.