Re: puzzlement over lazy sequences

2011-09-13 Thread Michael Gardner
On Sep 12, 2011, at 11:28 PM, Ken Wesson wrote: But if, as you say, take, drop, etc. work for larger n, it should be easy to make nth work with larger n and non-random-access seqs, just by changing the non-random-access case to (first (drop n the-seq)). I'd be rather surprised if nth suddenly

Re: puzzlement over lazy sequences

2011-09-13 Thread Ken Wesson
On Tue, Sep 13, 2011 at 2:39 AM, Michael Gardner gardne...@gmail.com wrote: On Sep 12, 2011, at 11:28 PM, Ken Wesson wrote: But if, as you say, take, drop, etc. work for larger n, it should be easy to make nth work with larger n and non-random-access seqs, just by changing the

Re: puzzlement over lazy sequences

2011-09-13 Thread Stefan Kamphausen
Hi, On Tuesday, September 13, 2011 6:28:01 AM UTC+2, Ken Wesson wrote: They're trees of arrays of 32 items, and the trees can in principle have arbitrary depth. So the 2^31 limit on Java arrays doesn't impact the Clojure collections, it seems. are you sure? As far as I understood things

Re: puzzlement over lazy sequences

2011-09-13 Thread Ken Wesson
On Tue, Sep 13, 2011 at 4:18 AM, Stefan Kamphausen ska2...@googlemail.com wrote: Hi, On Tuesday, September 13, 2011 6:28:01 AM UTC+2, Ken Wesson wrote: They're trees of arrays of 32 items, and the trees can in principle have arbitrary depth. So the 2^31 limit on Java arrays doesn't impact

Re: puzzlement over lazy sequences

2011-09-12 Thread Ken Wesson
On Mon, Sep 12, 2011 at 12:54 AM, Alan Malloy a...@malloys.org wrote: Integer overflow. user (mod 9876543210 (bigint (Math/pow 2 32))) 1286608618 Oops. But nth can probably be fixed while keeping good performance: (defn- small-drop [s n] (loop [n (int n) s (seq s)] (if (zero? n) s

Re: puzzlement over lazy sequences

2011-09-12 Thread Ken Wesson
On Mon, Sep 12, 2011 at 11:55 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: I'm guessing there are similar bugs in drop, take, and so forth with large n and large (or infinite) seqs. They should all be fixed. The other fns are ok, thanks to their separate heritage. drop, take, et al

Re: puzzlement over lazy sequences

2011-09-11 Thread Stuart Halloway
Hi George, Once again, I make a globally referenced, infinitely long stream. But now I use lazy-seq instead of cycle: user= (def ev-stream (lazy-seq (cons true (cons false ev- stream #'user/ev-stream user= (defn ev? [n] (nth ev-stream n)) #'user/ev? user= (time

Re: puzzlement over lazy sequences

2011-09-11 Thread Ken Wesson
On Sun, Sep 11, 2011 at 8:28 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: cycle actually calls lazy-seq.  A quick way to check such things at the REPL is with source: user= (source cycle) (defn cycle   Returns a lazy (infinite!) sequence of repetitions of the items in coll.   {:added

Re: puzzlement over lazy sequences

2011-09-11 Thread George Kangas
Hi, Stu, Loving your book! I posted a reply earlier, through a different interface, which went to moderators. Sorry for the clumsiness, but I'm not familiar with the mechanics of newsgroups. On Sep 11, 7:28 am, Stuart Halloway stuart.hallo...@gmail.com wrote: The consing version of

Re: puzzlement over lazy sequences

2011-09-11 Thread Alan Malloy
Integer overflow. user (mod 9876543210 (bigint (Math/pow 2 32))) 1286608618 On Sep 11, 9:44 pm, George Kangas gwkan...@gmail.com wrote: I believe the bug can be blamed on nth. Using nth, I make a function which should be identity on natural numbers: Clojure 1.2.1 user= (defn ident [n]

puzzlement over lazy sequences

2011-09-10 Thread George Kangas
Greetings, Clojurers! I've been playing with clojure, particularly with lazy sequences. Some of the results have left me puzzled, so I saved a REPL session wherein I illustrate the points of puzzlement. REPL lines are indented below; added comments are unindented. Clojure 1.2.1 I define a