)
>> Exit: Control+D or (exit) or (quit)
>> Results: Stored in vars *1, *2, *3, an exception in *e
>>
>> user=> (def a (atom {}))
>> #'user/a
>> user=> (swap! a assoc :self a)
>>
>> StackOverflowError java.util.regex.Pattern$GroupHead.match
oc: (javadoc java-object-or-class-here)
> Exit: Control+D or (exit) or (quit)
> Results: Stored in vars *1, *2, *3, an exception in *e
>
> user=> (def a (atom {}))
> #'user/a
> user=> (swap! a assoc :self a)
>
> StackOverflowError java.util.r
"part-of-name-here")
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
user=> (def a (atom {}))
#'user/a
user=> (swap! a assoc :self a
cumentation, disj works with sets. And doesn't it
>> recursive?
>>
>> О©╫О©╫О©╫О©╫О©╫О©╫О©╫, 8 О©╫О©╫О©╫О©╫О©╫О©╫ 2013О©╫О©╫., 13:17:28 UTC+4
>> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ ru О©╫О©╫О©╫О©╫О©╫О©╫О©╫:
>>>
>>> Dear clojure-users,
>>&g
chnique with better performance.
But, as I understand from scarce documentation, disj works with
sets. And doesn't it recursive?
пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал:
Dear clojure-users,
StackOverflowError clojure.lang.RT.nthFrom (
No, I am not in a hurry :) Thanks in advance.
пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал:
>
> Dear clojure-users,
>
> StackOverflowError clojure.lang.RT.nthFrom (RT.java:789)
>
> I got this error message during evaluation of "count" function c
я 2013 г., 13:17:28 UTC+4 пользователь ru написал:
>>
>> Dear clojure-users,
>>
>> StackOverflowError clojure.lang.RT.nthFrom (RT.java:789)
>>
>> I got this error message during evaluation of "count" function call on a
>> quite short list (abo
ль ru написал:
>
> Dear clojure-users,
>
> StackOverflowError clojure.lang.RT.nthFrom (RT.java:789)
>
> I got this error message during evaluation of "count" function call on a
> quite short list (about 200 elements). What can be reasons of the error.
>
On Fri, Nov 8, 2013 at 8:51 AM, ru wrote:
> Solution have found:
>
> (remove ...) => (doall (remove ...))
Be careful with this technique. It can easily make your O(n)
algorithm O(n^2). It may be better to use data structures that you
can use with conj and disj if you need to maintain performanc
> (filter #(not (some #{fid} (:FIDS (second % =CFSET=))
> (.remove =FIDS= fid)
> frame)))
>
> Thank you very much once more!
>
> Best regards,
> Ru
>
> пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал:
>>
>> Dear clojure-users,
ал:
>
> Dear clojure-users,
>
> StackOverflowError clojure.lang.RT.nthFrom (RT.java:789)
>
> I got this error message during evaluation of "count" function call on a
> quite short list (about 200 elements). What can be reasons of the error.
> Any hints would be greatly appr
ok we are getting somewhere...is it easy to post the source of your
'retract-fact' & 'fact_id' fns?
Jim
On 08/11/13 13:17, ru wrote:
Thank you, all, for the very useful information.
Stacktrace after StackOverflowError turns out:
StackOverflowError clojure.
Thank you, all, for the very useful information.
Stacktrace after StackOverflowError turns out:
StackOverflowError clojure.lang.RT.nth (RT.java:764)
rete.core=> (clojure.stacktrace/e)
java.lang.StackOverflowError: null
at clojure.lang.RT.nth (RT.java:764)
rete.core$fact_id.inv
On Friday, November 8, 2013 11:11:14 AM UTC+1, ru wrote:
>
> Hi Jim,
>
> I forget to say that call to count have been done in not a bare repl, but
> inside a quite complex program after it did a lot of work on a quite big
> data. But, after long and profound analysis of source code I did not fo
In this line:
(if TRACE (do (println [:OFACTS (count ofacts)])
(clojure.stacktrace/e)))
the StackOverflowError must be occurring in the evaluation of ofacts.
The error breaks out of the evaluation, preventing
(clojure.stacktrace/e) from being evaluated. The error sends you back to
the
On 08/11/13 10:46, ru wrote:
I am afraid, that I am not sure where to put (clojure.stacktrace/e) to
make it work :(
Or, may be this is not an exception?
use (clojure.stacktrace/e) after the exception has been thrown to get
some more information than just a line. Don't put it in your code, b
On Fri, Nov 8, 2013 at 5:11 AM, ru wrote:
> Hi Jim,
>
> I forget to say that call to count have been done in not a bare repl, but
> inside a quite complex program after it did a lot of work on a quite big
> data. But, after long and profound analysis of source code I did not found
> any places wit
I tryed to add a call (clojure.stacktrace/e) to the code after the call to
count like this:
...
(if TRACE (println [:ЩАС]))
(if TRACE (do (println [:OFACTS (count ofacts)])
(clojure.stacktrace/e)))
And what a result I have got:
...
[:ЩАС]
StackOverflowError
On 08/11/13 10:11, ru wrote:
I forget to say that call to count have been done in not a bare repl,
but inside a quite complex program after it did a lot of work on a
quite big data.
so your problem does not lie with 'count' but with something
else...actually 'count' doesn't hold on to the hea
filling
against my will...?
пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал:
>
> Dear clojure-users,
>
> StackOverflowError clojure.lang.RT.nthFrom (RT.java:789)
>
> I got this error message during evaluation of "count" function call on a
> quite
I cannot reproduce your result:
user=> (-> 500 range doall count)
500
user=> (-> 500 range count)
500
Could you provide more details? How exactly are you calling 'count' ?
Jim
On 08/11/13 09:17, ru wrote:
Dear clojure-users,
StackOverflowError clojure.lang.RT.nthFro
Dear clojure-users,
StackOverflowError clojure.lang.RT.nthFrom (RT.java:789)
I got this error message during evaluation of "count" function call on a
quite short list (about 200 elements). What can be reasons of the error.
Any hints would be greatly appreciated.
Since
> I think that falls under the heading of "don't do that." :)
I see.
Actually, I found the error when I just used clojure.test, like this:
(clojure.test/are [x y] (= (f x) y) 'x 'y) ;=> StackOverflowError
I think it's not as much obvious as clojure.template
wrote:
>
> Hi,
>
> I've run into such an error:
>
> (clojure.template/apply-template '[x] 'x '[[x]]) ;=>
> StackOverflowError
>
> It appears to be caused by replacing x with [x] infinitely
> recursively. Is it a bug or spec?
--
You receive
Hi,
I've run into such an error:
(clojure.template/apply-template '[x] 'x '[[x]]) ;=>
StackOverflowError
It appears to be caused by replacing x with [x] infinitely
recursively. Is it a bug or spec?
--
You received this message because you are subscribed to the Google
hrieb Alf:
>
> >> What am I doing wrong here, will filter/remove or something else give
> >> StackOverflowError when used incorrectly?
>
> > Yes. You pile lazy seq on lazy seq on lazy seq on and then realise the
> > first element. This kicks off a cascade which fina
Jup, that solved the problem. Lesson learned.
>>
>> Thanks :)
>> Alf
>>
>>
>>
>> On Thu, Sep 22, 2011 at 17:54, Meikel Brandmeyer (kotarak)
>> wrote:
>> > Hi,
>> >
>> > Am Donnerstag, 22. September 2011 17:43:30 UTC+2 schrieb A
m I doing wrong here, will filter/remove or something else give
> >> StackOverflowError when used incorrectly?
> >
> > Yes. You pile lazy seq on lazy seq on lazy seq on and then realise
> the
> > first element. This kicks off a cascade which finally causes the stack
>
r something else give
>> StackOverflowError when used incorrectly?
>
> Yes. You pile lazy seq on lazy seq on lazy seq on and then realise the
> first element. This kicks off a cascade which finally causes the stack
> overflow when your lazy seq pile is large enough.
>
> Put a doall
Hi,
Am Donnerstag, 22. September 2011 17:43:30 UTC+2 schrieb Alf:
>
>
> What am I doing wrong here, will filter/remove or something else give
> StackOverflowError when used incorrectly?
>
Yes. You pile lazy seq on lazy seq on lazy seq on and then realise the
first element. T
m I doing wrong here, will filter/remove or something else give
StackOverflowError when used incorrectly?
Cheers,
Alf
--
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
Note that p
Alan Malloy writes:
> On Aug 26, 12:40 pm, Tassilo Horn wrote:
>> Paul Mooser writes:
>>
>> Hi Paul,
>>
>> > If you search for "filter" and "StackOverflowError" in this group, you
>> > will find people discussing related issue
On Aug 26, 12:40 pm, Tassilo Horn wrote:
> Paul Mooser writes:
>
> Hi Paul,
>
> > If you search for "filter" and "StackOverflowError" in this group, you
> > will find people discussing related issues.
>
> Thanks, I've found some explanation
Paul Mooser writes:
Hi Paul,
> If you search for "filter" and "StackOverflowError" in this group, you
> will find people discussing related issues.
Thanks, I've found some explanation by Meikel Brandmeier who explains
the layering issue. But do we really
Tassilo Horn writes:
Now I'm really a bit confused. I've just added atom counters and
increased them in the comparison functions in order to check if the lazy
variants really test less than the standard sort.
> A better solution [that doesn't overrun the stack] seems to be to use
> a sequence c
If you search for "filter" and "StackOverflowError" in this group, you
will find people discussing related issues.
On Aug 26, 10:30 am, Tassilo Horn wrote:
> Do you have a link to the issue? I've tried searching for "filter" or
> "layer" at dev
Tassilo Horn writes:
>> I've seen people solve these issues by forcing the intermediate seqs,
>> but that doesn't work well for a lazy situation such as this.
>
> Indeed, putting a doall around the filter and remove seems to prevent
> the stack overflow.
A better solution seems to be to use a se
Paul Mooser writes:
Hi Paul,
> Looking at the stack trace, I suspect this is the old problem of
> layering too many filters on top of the same seq. If I understand the
> issue correctly, when you have enough layers of filter on top of a
> seq, when you finally try to access elements, as it eval
Looking at the stack trace, I suspect this is the old problem of
layering too many filters on top of the same seq. If I understand the
issue correctly, when you have enough layers of filter on top of a
seq, when you finally try to access elements, as it evaluates each
layer, it is going to be makin
> (time (first (sort (take 1000 (iterate dec 500)
"Elapsed time: 7.298069 msecs"
-499
--8<---cut here---end--->8---
But that's only the minor issue. The major issue is that I get a
StackOverflowError when the seq passed to qsort becomes too large
Hi,
Am 06.12.2010 um 22:38 schrieb Ken Wesson:
> A reduce that discards one of its arguments (e.g. (reduce (fn [n _]
> (inc n)) coll)) also strikes me as slightly icky. :)
Indeed this would fit in the 5% left. Anyway: I can't remember writing a
function with accumulator not using the other argu
On Mon, Dec 6, 2010 at 11:36 AM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 06.12.2010 um 11:40 schrieb Ken Wesson:
>
>> Won't that make the internal recursive call fail though?
>
> No. Because the metadata is just documentation.
>
>> And even if not -- ugly IMO. :)
>
> Tastes vary. I prefer this over
Hi,
Am 06.12.2010 um 11:40 schrieb Ken Wesson:
> Won't that make the internal recursive call fail though?
No. Because the metadata is just documentation.
> And even if not -- ugly IMO. :)
Tastes vary. I prefer this over a second toplevel function named foo-aux or the
like. I also prefer it ov
On Dec 6, 11:40 am, Ken Wesson wrote:
> Won't that make the internal recursive call fail though?
>
> And even if not -- ugly IMO. :)
Agree. Why make something slower and more ugly?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this grou
On Mon, Dec 6, 2010 at 5:19 AM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 06.12.2010 um 10:14 schrieb Ken Wesson:
>
>>> Then we could use arity functions. (Alex Osborne)
>>>
>>> (defn list-length
>>> ([coll] (list-length coll 0))
>>> ([coll n] (if-let [s (seq coll)]
>>>
Hi,
Am 06.12.2010 um 10:14 schrieb Ken Wesson:
>> Then we could use arity functions. (Alex Osborne)
>>
>>(defn list-length
>> ([coll] (list-length coll 0))
>> ([coll n] (if-let [s (seq coll)]
>> (recur (rest s) (inc n))
>> n)))
>>
>> This
I didn't expect my question would initiate such a wonderful
discussion, I'm speechless.
Thank you all guys, you are amazing.
Alex, your posts killed in a very good way :)
It was really helpful to morph the code and transform it.
On Dec 6, 11:14 am, Ken Wesson wrote:
> On Mon, Dec 6, 2010 at 4:02
On Mon, Dec 6, 2010 at 4:02 AM, nickik wrote:
> The easy (and good) solution is to pass the running result onlong the
> way. This can be done in diffrent ways.
>
> First the CL Style where you creat a new function in you function that
> then does all the work. (from
> Ken Wesson)
>
> (defn list-le
> What is the difference between rest and next?
This has to do with lazyness. I wrote an answer to that on
stackoverflow.
http://stackoverflow.com/questions/4288476/clojure-rest-vs-next
Should answer everthing.
> I'm confused, should I use empty? or not? when to use it?
> Why Clojure decided to
HB writes:
> Ken & Alex,
> Why you aren't calling empty? when you want to check if a collection
> is empty?
Here's the definition of empty? from clojure/core.clj:
(defn empty?
"Returns true if coll has no items - same as (not (seq coll)).
Please use the idiom (seq x) rather than
HB writes:
> OMG, this is too much Clojure code for me to handle O.o
> Alex, you just killed me :)
Hehe, sorry. Just thought it might be helpful to show the progression
of dealing with all the little edge cases.
It perhaps looks much more fiddly, but you're doing more there than
common lisp:
On Sun, Dec 5, 2010 at 6:55 PM, HB wrote:
> Ken & Alex,
> Why you aren't calling empty? when you want to check if a collection
> is empty?
>
> Isn't (if s) supposed to return true if s is empty ?
If coll is empty, (seq coll) and (next coll) are both nil, which is
logical false.
--
You received
Ken & Alex,
Why you aren't calling empty? when you want to check if a collection
is empty?
Isn't (if s) supposed to return true if s is empty ?
On Dec 6, 12:27 am, Ken Wesson wrote:
> On Sun, Dec 5, 2010 at 5:16 PM, Robert McIntyre wrote:
> > Your function never actually ends because even the
not a sequence, for example a hash-map, then it doesn't have to be
> converted to a seq twice.
>
> The above will still blow up with a StackOverflowError on very large
> lists because it is not tail-recursive. We can transform it into a
> tail-recursive form by passing the count-
In Clojure, empty sequences are not considered logically false, so
your code continues going after reducing col to an empty list. You
need to explicitly check whether the collection is empty, like so:
(defn list-length [col]
(if (empty? col)
0
(+ 1 (list-length (rest col)
Cheers,
N
(+ 1 (list-length (rest s)))
0))
The seq function will return nil on an empty sequence. It's also good
form to capture its output as s, so that if you pass in something that's
not a sequence, for example a hash-map, then it doesn't have to be
converted to a seq
What is the difference between rest and next?
I'm confused, should I use empty? or not? when to use it?
Robert,
Your code is working but if I use empty? , it returns 0 instead of the
actual count.
Why?
Why Clojure decided to handle an empty list as a not false? this is a
big (if not) departure f
On Sun, Dec 5, 2010 at 5:16 PM, Robert McIntyre wrote:
> Your function never actually ends because even the empty list
> evaluates to true :)
>
> rlm.dna-melting> (if (rest '()) true false)
> true
>
> rlm.dna-melting> (if (next '()) true false)
> false
>
> so, changing your list length function t
Your function never actually ends because even the empty list
evaluates to true :)
rlm.dna-melting> (if (rest '()) true false)
true
rlm.dna-melting> (if (next '()) true false)
false
so, changing your list length function to use next will work
rlm.dna-melting> (defn list-length [col] (if col (+
On Dec 5, 9:52 pm, HB wrote:
> Hi,
> I'm trying to write a function that calculates the length of a list:
>
> (defn list-length [col]
> (if col
> (+ 1 (list-length(rest col)))
> 0))
>
> (list-length '(Java, Clojure, Scala))
>
> Upon running it in the REPL, I got the error:
> java.lang.St
Hi,
I'm trying to write a function that calculates the length of a list:
(defn list-length [col]
(if col
(+ 1 (list-length(rest col)))
0))
(list-length '(Java, Clojure, Scala))
Upon running it in the REPL, I got the error:
java.lang.StackOverflowError (test.clj:3)
What is going wron
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
Yes, I meant all primes under 200. Also, thanks for the tips, I'll
go fix the code right away.
Nebojsa
--
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
Note that posts from new members
2010/1/27 Meikel Brandmeyer :
> Dang. Details matter.
:-)
2010/1/27 Nebojsa Stricevic :
> I've transformed algorithm to this:
>
> [ ... elided ... ]
>
> And I think, that this is real SoE, and it can calculate sum of first
> 200 prime numbers in ~35 sec, on 1.4 Celeron M.
I'd go as far as to
2010/1/27 Christophe Grand :
> See
> http://clj-me.cgrand.net/2009/07/30/everybody-loves-the-sieve-of-eratosthenes/
> for other impls of the SoE -- there was no transients at the time but
> they are fast... and can be transientified.
Oh, that's really cool, Christophe! Very elegant as well as *fa
I've transformed algorithm to this:
(defn primes-bellow
"calculates all primes bellow max"
[max]
(loop [numbers (vec (range 2 max)) primes [] last-p 0]
(let [p (first (drop-while zero? (drop (dec last-p) numbers)))]
(if (> p (. Math s
Hi,
Am 27.01.2010 um 17:57 schrieb Michał Marczyk:
> while the end result is the same, the time complexity of the algorithm
> is definately not. The exact difference is calculated in Melissa E.
> O'Neill's paper, "The Genuine Sieve of Eratosthenes".
Dang. Details matter.
Sincerely
Meikel
--
Y
. I wrote function for calculating prime number below some
> integer value max. But it doesn't work for large numbers, causing
> StackOverflowError.
>
> (defn primes-below
> "calculates all primes bellow max"
> [max]
> (loop [numbers (ran
Hi,
On Wed, Jan 27, 2010 at 5:57 PM, Michał Marczyk
wrote:
> I've had a go at implementing an incremental SoE-like sieve in Clojure:
>
> http://gist.github.com/287986
>
> It uses transients and appears to be quite a lot faster than the
> clojure.contrib.lazy-seq/primes implementation, although re
Meikel,
while the end result is the same, the time complexity of the algorithm
is definately not. The exact difference is calculated in Melissa E.
O'Neill's paper, "The Genuine Sieve of Eratosthenes" [1], which also
includes some highly performant implementations of incremental
SoE-like prime numb
Hi,
On Jan 27, 2:43 pm, "twitter.com/nfma"
wrote:
> hmm... I'm just learning clojure at the moment but by looking at code what I
> see is:
>
> 1 - A collecting parameter called primes
> 2 - A test to verify if a number is a prime by calculating the reminder of
> the division with all (or some) o
You are right. This isn't exactly sieve of Eratosthenes. My plan was
to implement it, but instead, I wrote this, because it was simpler (at
least for my knowledge of Clojure). But since it's too slow, I'll
transform it to real sieve of Eratosthenes, to check it's performance.
On Jan 27, 2:43 pm, "
hmm... I'm just learning clojure at the moment but by looking at code what I
see is:
1 - A collecting parameter called primes
2 - A test to verify if a number is a prime by calculating the reminder of
the division with all (or some) of the primes already found
3 - if a number is a prime then its a
Hi,
On Jan 26, 5:38 pm, "twitter.com/nfma"
wrote:
> You can use the sieve of Eratosthenes...
This actually is the sieve of Eratosthenes. If one really wants to go
out of one's way, one can investigate the sieve of Atkin (or other
improved variants) and the the various ways of optimising the
alg
You can use the sieve of Eratosthenes...
2010/1/26 Nebojsa Stricevic
> Thanks a lot for help. I have much better understanding of laziness
> now! But I guess I'll need to do some more math research, because both
> algorithms provided here (my + removed laziness and the one from
> Meikel) are too
Thanks a lot for help. I have much better understanding of laziness
now! But I guess I'll need to do some more math research, because both
algorithms provided here (my + removed laziness and the one from
Meikel) are too slow for calculating all primes below 200.
On Jan 26, 4:48 pm, Chouser wr
On Tue, Jan 26, 2010 at 9:52 AM, Meikel Brandmeyer wrote:
> Hi Chris,
>
> On Jan 26, 3:33 pm, Chouser wrote:
>
>> Of course with this algorithm you *need* filter to be lazy, or
>> you'd never get past the first iteration of the loop.
>
> I'm sorry. I have to ask.
>
> Why?
Hm, now that you ask, I
Hi,
On Jan 26, 3:17 pm, Nebojsa Stricevic
wrote:
> I'm new to Clojure and working my way through Project Euler problems
> for learning. I wrote function for calculating prime number below some
> integer value max. But it doesn't work for large numbers, causing
> StackOv
> There are a few options, but I suppose you don't want too many hints yet?
Oops..
--
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
Note that posts from new members are moderated - please b
Hi Chris,
On Jan 26, 3:33 pm, Chouser wrote:
> Of course with this algorithm you *need* filter to be lazy, or
> you'd never get past the first iteration of the loop.
I'm sorry. I have to ask.
Why?
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups
t; > I'm new to Clojure and working my way through Project Euler problems
> > for learning. I wrote function for calculating prime number below some
> > integer value max. But it doesn't work for large numbers, causing
> > StackOverflowError.
>
> > (defn primes-bel
or large numbers, causing
> StackOverflowError.
>
> (defn primes-below
> "calculates all primes bellow max"
> [max]
> (loop [numbers (range 2 max) primes []]
> (if (empty? numbers)
> primes
>
Greetings,
I'm new to Clojure and working my way through Project Euler problems
for learning. I wrote function for calculating prime number below some
integer value max. But it doesn't work for large numbers, causing
StackOverflowError.
(defn primes-below
"calculates al
Hi Robert,
I tracked down the source of the StackOverflowError in my code. It
boils down to the following similar (to your example) code snippet.
Although, on my machine, this example gives the stack overflow, rather
than the OOM error.
(def acoll (ref []))
(doseq [i (range 1 3000)]
(println
Hi Robert,
Thanks for your reply! Very interesting. I see what you're saying.
But, your code results in a OutOfMemoryError, rather than a
StackOverflow.
At least, that's what I see on my machine. Are you seeing the same?
Is there some way that this same concept could lead to a
StackOverflow?
Hi Kyle!
I encountered the same problem:
(defn stack-fail
"returns an empty lazy seq"
[l i]
(if (> i 0)
(recur (remove #{1} (concat l '(1))) (dec i))
l))
(def foo (stack-fail () 1000))
foo
; Evaluation aborted.
if you call a non-lazy function (e.g. doall) on the collection from
t
Is it possible that the Clojure core seq function can cause a stack
overflow (since it calls itself)?
Or is there some other manner in which misuse of a lazy seq could
cause this? In the stack trace below, I'm seeing repeated calls to
"seq" in clojure core, until the stack is blown.
Thanks,
Kyle
The function returns a map with the keys being word pairs and the
value being a single word. It is a component of a larger program.
user=> (generate-chain "a quick brown fox jumps over the lazy dog")
{("the" "lazy") ("dog"), ("over" "the") ("lazy"), ("jumps" "over")
("the"), ("fox" "jumps") ("ove
009 at 1:02 PM, tmountain wrote:
>
> > Hi all - I've recently encouraged a friend to start learning Clojure,
> > and he has written some basic Markov chaining code as a learning
> > exercise. His code works fine with small sets of input data, but
> > larger inputs hav
On Sep 2, 7:02 pm, tmountain wrote:
> (defn generate-chain [source]
> (loop [the-list (map #(list (first (split-at 2 %)) (last %))
> (partition 3 1 (.split (.replace source "\n" "
> ") " ")))
> res (hash-map)]
> (if (empty? the-list)
> res
> (rec
have been causing a StackOverflowError.
>
> I've taken a look at the code and suspect that the error may be caused
> by recurrent calls to filter occupying increasing amounts of stack
> space due to filter leaving closed-over locals hanging around. That
> being said, this is
Hi all - I've recently encouraged a friend to start learning Clojure,
and he has written some basic Markov chaining code as a learning
exercise. His code works fine with small sets of input data, but
larger inputs have been causing a StackOverflowError.
I've taken a look at the code a
Hi Chrisophe,
You are correct, the doall also solves the problem.
Based on that, I moved the doall out of matrixMultiply and into the
computeActualResponse function, so that the caller can decide whether
they want lazy evaluation for matrixMultiply or not:
(defn computeActualResponse [signumFun
Hello,
(def lazy-identity [x] (lazy-seq x))
(nth (iterate lazy-identity [1 2]) 10) ; returns (1 2)
(nth (iterate lazy-identity [1 2]) 1000) ; returns (1 2)
(nth (iterate lazy-identity [1 2]) 10) ; (with my JVM settings)
throws a StackOverflowException
Each time that you are building a lazy
Hi Jleehurt,
I'm still newbie and don't know, but you have at least two recursive
functions - matrixAdd, and matrixMultiplyScalar.
I've modified them to work with loop/recur, but I can't tell whether
they are with same efficiency (at least no stack problem).
Still if I remove the "dorun" from t
1 - 100 of 106 matches
Mail list logo
