Re: strange bug in range or lazy-seq?

2010-10-13 Thread Stuart Halloway
After thinking about it some more, I don't understand it either. I have created a ticket for this: https://www.assembla.com/spaces/clojure/tickets/457-lazy-recursive-definition-giving-incorrect-results. As a workaround, eliminate the lazy intermediary nums sequence, e.g. (def primes (concat

Re: strange bug in range or lazy-seq?

2010-10-12 Thread babui
On 12 oct, 03:56, Stuart Halloway stuart.hallo...@gmail.com wrote: I've tried your definition (def primes   (concat    [2]    (let [primes-from          (fn primes-from            [n]            (if (some #(zero? (rem n %))                      (take-while #(= (* % %) n) primes))        

Re: strange bug in range or lazy-seq?

2010-10-12 Thread Jason Wolfe
On Oct 11, 6:56 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: When a var's definition has a lazy reference to itself, as primes does below, then your results will be dependent on the lazy/chunky/strict-ness of the calls leading to the lazy reference. While I agree that this sort of

Re: strange bug in range or lazy-seq?

2010-10-12 Thread SpiderPig
Thank you all for explaining this to me but I still don't understand clojures behavior in this case, Try running this code: (def nums (drop 2 (range))) (def primes (cons (first nums) (lazy-seq (- (rest nums) (remove (fn [x]

Re: strange bug in range or lazy-seq?

2010-10-12 Thread Stuart Halloway
Sorry, that should have been (def primes (concat [2] (lazy-seq (let [primes-from (fn primes-from [n] (if (some #(zero? (rem n %)) (take-while #(= (* % %) n) primes)) (recur (+ n 2)) (lazy-seq (cons n

Re: strange bug in range or lazy-seq?

2010-10-12 Thread Paul Mooser
Any chance someone could walk us through how this visibility issue occurs (where the range-based version of primes consumes numbers before they are visible). This really looks like a case where side effects and implementation details are causing what appear to be strange behaviors, based on

strange bug in range or lazy-seq?

2010-10-11 Thread SpiderPig
Hi, I tried experimenting with lazy sequences and wrote this program (def nums (cons 2 (lazy-seq (map inc nums (def primes (cons (first nums) (lazy-seq (- (rest nums) (remove (fn [x] (let [dividors (take-while

Re: strange bug in range or lazy-seq?

2010-10-11 Thread Alan
I confess I'm a bit baffled by this too, but I have a couple suggestions that don't address your problem :) (drop 2 (range)) is the same as (iterate inc 2), and the same as your convoluted lazy-seq, except that the iterate works here, while for some reason the range doesn't. You might consider

Re: strange bug in range or lazy-seq?

2010-10-11 Thread Sam Roberton
(def nums (cons 2 (lazy-seq (map inc nums (def primes (cons (first nums)              (lazy-seq (-                (rest nums)                (remove                  (fn [x]                    (let [dividors (take-while #(= (* % %) x) primes)]                      (some #(= 0 (rem x

Re: strange bug in range or lazy-seq?

2010-10-11 Thread Stuart Halloway
When a var's definition has a lazy reference to itself, as primes does below, then your results will be dependent on the lazy/chunky/strict-ness of the calls leading to the lazy reference. The functions range, rest, and remove are chunk-aware, so the range-based version of primes consumes a