Yes, it is. I reworked my code and removed where it is possible global
assignments through *def*, particulary, from the function *retract-fact*.
But, I can not do without global mutations altogether, so I have to use
atom, ref, agent etc., as you suggested. But, do mutation of these
structures
Hi Ru,
Think of it this way...In Java you can't declare something as public
from within a method. Ok, in Java this would break the object's contract
but even if you look at languages like python, you still don't define
global variables from within functions. I have seen python code where
fun
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 call on a
> quite short list (
You don't generally do global variable assignment in Clojure...it is
seriously frowned upon and goes against the functional paradigm... I need
to run now and I will be busy for the next 2 hours... perhaps someone else
can explain if you are in a hurry?
On Nov 8, 2013 2:34 PM, "ru" wrote:
> Jim, p
Jim, please, recommend a correct solution for global variable assignment.
John, Indeed I would prefere technique 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 нап
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
Did I see a def inside a defn? This is weird... glad you solved your
problem though...
On Nov 8, 2013 1:51 PM, "ru" wrote:
> Solution have found:
>
> (remove ...) => (doall (remove ...))
>
> Full source of 'retract-fact' function is:
>
> (defn retract-fact [fid]
> "Retract fact for given fact-i
Solution have found:
(remove ...) => (doall (remove ...))
Full source of 'retract-fact' function is:
(defn retract-fact [fid]
"Retract fact for given fact-id by removing it from alpha, beta and fact
memory,
and also by removing from conflict set activations, containing this
fact-id"
;;(p
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.lang.RT.nth (RT.java:764)
rete.co
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.invoke (core.clj
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 Clo
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 clojure.lang.RT.nt
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
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 with deep recursive calls :( Something like stack is f
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.nthFrom (RT.java:789)
I got
> 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's case.
At that time, I didn't know
I think that falls under the heading of "don't do that." :)
clojure.template (which I wrote) wasn't a great idea to begin with. It was
slightly useful in clojure.test, but I haven't found a use for it since.
-S
On Sunday, April 22, 2012 8:02:45 AM UTC-4, Shogo Ohta wrote:
>
> Hi,
>
> I've run
FWIW there's a lot of prior threads about this problem in various
guises. The one I like to refer people to is on stackoverflow, and is
for exactly what you're doing:
http://stackoverflow.com/questions/2946764/recursive-function-causing-a-stack-overflow
On Sep 22, 9:36 am, Alf Kristian Støyle
wro
Well, why reinvent the wheel :)
https://github.com/richhickey/clojure-contrib/blob/78ee9b3e64c5ac6082fb223fc79292175e8e4f0c/src/main/clojure/clojure/contrib/lazy_seqs.clj#L66
Cheers,
Alf
On Thu, Sep 22, 2011 at 19:20, Wilker wrote:
> Alf, I mean it will be even better if you just generate an
Alf, I mean it will be even better if you just generate an infinite lazy
sequence that generates primes, I mean will be really more cool :)
---
Wilker Lúcio
http://about.me/wilkerlucio/bio
Kajabi Consultant
+55 81 82556600
On Thu, Sep 22, 2011 at 1:36 PM, Alf Kristian Støyle wrote:
> Jup, that
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 Alf:
>>
>> What am I doing wrong here, will filter/remove or something else give
>> StackOverflowErr
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. This kicks off a c
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 issues.
>>
>> Thanks, I've found some explanation by Meikel Brandmeier wh
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 by Meikel Brandmeier who explains
> the layering issue.
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 have to live with that?
I mean, repla
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.clojure.org, but I can't find anything...
--
You
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
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
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
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
Hi Dimiter,
Thank you! I'm still a bit confused as to why this was happening. Does
lazy evaluation not work well with recursion?
On Apr 20, 11:06 pm, "Dimiter \"malkia\" Stanev"
wrote:
> I blindly tried printing out stuff from matrixMultiply, and found out
> that if I print matrixA and matrixB
I blindly tried printing out stuff from matrixMultiply, and found out
that if I print matrixA and matrixB it doesn't run out of stack, so I
guess I was "forcing" them to "work", here is a version with (dorun)
that has the same side effect, without printing:
(defn matrixMultiply [matrixA matrixB]
Hi David,
Those two are not recursive, but they call into other functions that
are. Do I need to make sure that all recursive functions use the loop/
recur pattern? Or should I not nest recursive calls like this?
Here is the whole source:
;; Neuron Activation Functions
;threshold
(defn thresho
Hi David,
Those two are not recursive, but they call into other recursive
functions. Do I need to make sure all recursive functions use the loop/
recur pattern? Or maybe not nest recursive calls like this?
Here is the whole source:
;threshold
(defn threshold [x] (if (>= x 0) 1 0))
;signum (thr
You have two other function calls
getAdaptedWeightVector
computeActualResponse
Are these recursive as well?
On Sun, Apr 19, 2009 at 11:26 PM, jleehurt wrote:
>
> Hi all, I have the following code that trains a perceptron with the
> given inputs and corresponding desired inputs. For input/output
45 matches
Mail list logo
