coding-dojo-20110921

gistfile1.clj

(defn primes [n] nil
  (reverse
   (loop [candidate 2 current n acc []]
     (if (zero? current)
       acc
       (if (every? #(not= 0 (rem candidate %)) acc)
         (recur (inc candidate) (dec current) (cons candidate acc))
         (recur (inc candidate) current       acc))))))

(fact
 (primes 1) => [2]
 (primes 2) => [2 3]
 (primes 3) => [2 3 5])

interessant, j'aurais bien vu une version avec iterate aussi ... 2011/9/21 Laurent Petit < [email protected]>

…

Je me suis amus faire une version lazy, sans chercher modifier l'algorithme initial (donc c'est du lazy qui retient la head, pire, qui double la taille de la liste en memoire. Mais c'est du lazy :-) ) : https://gist.github.com/1233437 ## Reply to this email directly or view it on GitHub: https://gist.github.com/1231894

2011/9/21 Laurent Petit < [email protected]>

Ah oui, en haut de votre fonction, il y a un nil qui trane

oui c'est parce qu'on la faite en TDD: un squelette d'implem (d'ou le nil), puis le test puis implem, sauf qu'on a oublie d'enlever le nil `

…

## Reply to this email directly or view it on GitHub: https://gist.github.com/1231894

avec iterate, je ne vois pas comment faire pour passer l'accumulateur. A moins que le iterate itere autour du couple (candidate / accumulateur ), et que l'iterate soit "coiffé" par un map qui retourne à chaque niveau le (first) de l'accumulateur :
(map (comp first second) (iterate (fn [[candidate acc]] ....) [2 []])
mais ca commence p-e alors à faire beaucoup de créations d'objets intermédiaires (enfin tant qu'on n'a pas mesuré, bien sûr ...)

Menfin le décompte des objets intermédiaires quand on utilise un algo naïf c'est pas important. Là on est dans une approche parnassienne du code. https://gist.github.com/1236838#comments

"Le code pour le code."