The points the others have made are true, but not likely the true cause of
your memory blow-up.
I believe the real source of your problem has to do with Clojure's use of
chunked sequences rather than truly lazy sequences, which can bite you in
scenarios like this one. (range 10) produces a single chunk, so because of
the way that for, map, filter, and remove work on chunked sequences, the
entire permutations sequence is generated all at once and not lazily.
So your original solution was reasonable, but you need to "unchunk" (range
10) before you pass it to the permutations function. One way to do that is
with this function:
(defn- unchunk
"Given a sequence that may have chunks, return a sequence that is 1-at-a-time
lazy with no chunks. Chunks are good for efficiency when the data items are
small, but when being processed via map, for example, a reference is kept to
every function result in the chunk until the entire chunk has been processed,
which increases the amount of memory in use that cannot be garbage
collected."
[s]
(lazy-seq
(when (seq s)
(cons (first s) (unchunk (rest s))))))
BTW, it's a perfectly good, valuable learning experience to write
permutations on your own, but you'll get better performance if you use the
implementation in clojure.math.combinatorics:
https://github.com/clojure/math.combinatorics
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
