As the sequence is very cheap to calculate it is difficult to see the benefit of keeping it in memory under any circumstances. I would replace the one in contrib with Christophe's short, easy to understand implementation. Caching values isn't getting you anywhere; just wasting resources.
Chris On Feb 23, 12:51 pm, "Stephen C. Gilardi" <squee...@mac.com> wrote: > On Feb 23, 2009, at 11:43 AM, Stuart Halloway wrote: > > > Also, the current 'fibs' implementation in clojure.contrib.seq fails > > the test above, because it holds the entire sequence as it goes. We > > should replace it with whatever the community comes up with on this > > thread. > > The fibs implementation in clojure.contrib.lazy-seqs is not a function > that returns fib(n) given n. Instead, it is an infinite sequence of > all the fibonacci numbers. It holds onto its head because it's > intended to. It's surely not the right way to deal with fibonacci > numbers in every context, but I don't think it needs replacing because > it requires a large java heap to pass this test: > > (rem (nth clojure.contrib.lazy-seqs/fibs 1000000) 1000) > -> 875 > > I think defining a fib(n) function somewhere in contrib or core that > operates as efficiently as we can manage would be a good idea. > > --Steve > > smime.p7s > 3KViewDownload --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
