On Tue, Sep 13, 2011 at 4:18 AM, Stefan Kamphausen
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
>> the Clojure c
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 thi
On Tue, Sep 13, 2011 at 2:39 AM, Michael Gardner 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 non-random-access case to (
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 sudden
On Mon, Sep 12, 2011 at 11:55 AM, Stuart Halloway
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
> are sequence functions,
> 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 are
sequence functions, and proceed iteratively.
nth is of a different lineage. It w
On Mon, Sep 12, 2011 at 12:54 AM, Alan Malloy 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 (recur (dec n)
Integer overflow.
user> (mod 9876543210 (bigint (Math/pow 2 32)))
1286608618
On Sep 11, 9:44 pm, George Kangas 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] (nth (ite
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] (nth (iterate inc 0) n))
#'user/ident
And it works, for reasonable size numbers:
user=> (ident 12345)
12345
user=> (ident 7654321)
7654321
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 wrote:
> The consing version of ev-stream is self-referentia
On Sun, Sep 11, 2011 at 8:28 AM, Stuart Halloway
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 "1.0"
> :stat
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?
>
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
13 matches
Mail list logo
