On Wed, Nov 3, 2010 at 2:35 AM, Meikel Brandmeyer wrote:
> Hi,
>
> On 3 Nov., 00:40, Rasmus Svensson wrote:
>
>> I think the problem is that this reduction will build an expression like
>> this:
>>
>> (map + ... (map + ... (map + ... (map + ... > levels>
>>
>> When clojure tries to reali
Hi,
On 3 Nov., 00:40, Rasmus Svensson wrote:
> I think the problem is that this reduction will build an expression like this:
>
> (map + ... (map + ... (map + ... (map + ... levels>
>
> When clojure tries to realize an element of the resulting lazy seq,
> every level will result in a ne
2010/11/3 John Szakmeister :
> I'm sorry... I don't quite understand this explanation. Do you mean
> that reduce is realizing the entire list all at once? I would think
> it would grab an element one at a time. Sorry for the stupid
> question, but there's something subtle here that I'm not
> und
On Tue, Nov 2, 2010 at 4:49 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 02.11.2010 um 12:58 schrieb Pepijn de Vos:
>
>> The one-liner:
>> http://gist.github.com/659491
>
> I would expect this is because you pile lazy seq on lazy seq, which then get
> realised, unfolding the whole thing resulting in
Hi,
Am 02.11.2010 um 12:58 schrieb Pepijn de Vos:
> The one-liner:
> http://gist.github.com/659491
I would expect this is because you pile lazy seq on lazy seq, which then get
realised, unfolding the whole thing resulting in the stack overflow. Try this:
user=> (reduce #(doall (map + %1 %2)) (
Hi all,
Usually my 'bugs' are in my own code, but this time I talked to three of four
people on IRC and came up with a one-liner that suffers the same problem my
project has.
I was optimizing some code to not retain the head of the sequence, but when I
put a map inside a reduce over a gigantic
