I think using eval is generally considered an antipattern. It's
generally slow, and it's easy to make confusing code with it.
Phlex - thanks for the suggestion. I may give that a try.
Rich - thanks for the fix. I'm trying it now. It looks like it's not
experiencing any permanent growth, though i
Thanks for the explanation, Meikel.
My statement about anti-pattern was predicated on each call to fn[]
creating a new class - I see from your explanation and from going back
and re-reading Rich's old posts on this topic that I misunderstood it
before. (If it did create a new class each time, I'd
On Jan 25, 2009, at 5:13 AM, Christophe Grand wrote:
>
> Zak Wilson a écrit :
>> Thanks, Christophe. It works now, and it's fast.
>>
>> Unfortunately, now I've run in to Nathan's problem. After a few
>> thousand generations, resulting in the creation of about half a
>> million functions it was u
On Sun, Jan 25, 2009 at 11:13 AM, Christophe Grand
wrote:
> Zak Wilson a écrit :
>> know the JVM very well at all. Are there any ways around this? Are
>> techniques that generate a lot of short-lived functions just not
>> practical in Clojure?
>>
> Yes there are a way around this: permgen memory
Zak Wilson a écrit :
> Thanks, Christophe. It works now, and it's fast.
>
> Unfortunately, now I've run in to Nathan's problem. After a few
> thousand generations, resulting in the creation of about half a
> million functions it was using over a gig of memory and died with an
> OutOfMemoryError.
Phlex wrote:
> How about compiling a closure tree ?
>
> ;; very basic example follows
>
> (defn make+ [param1 param2]
> (fn [environement]
> (+ (param1 environement) (param2 environement
>
> (defn make* [param1 param2]
> (fn [environement]
> (* (param1 environement) (param2 envir
How about compiling a closure tree ?
;; very basic example follows
(defn make+ [param1 param2]
(fn [environement]
(+ (param1 environement) (param2 environement
(defn make* [param1 param2]
(fn [environement]
(* (param1 environement) (param2 environement
(defn make-variable [
Hi,
Am 25.01.2009 um 08:41 schrieb Greg Harman:
This could be a real problem for Clojure. I can think of other
techniques that could easily result in the creation a large number of
anonymous functions that ought to get gc'd after a few ms but
permanently increase memory usage by a significant a
> This could be a real problem for Clojure. I can think of other
> techniques that could easily result in the creation a large number of
> anonymous functions that ought to get gc'd after a few ms but
> permanently increase memory usage by a significant amount. I don't
> know the JVM very well at
Thanks, Christophe. It works now, and it's fast.
Unfortunately, now I've run in to Nathan's problem. After a few
thousand generations, resulting in the creation of about half a
million functions it was using over a gig of memory and died with an
OutOfMemoryError. While let-eval is cool, using it
You must eval the whole fn form:
(defn compile-rule [body]
(eval (list `fn '[a b] body)))
user=> (let [f (compile-rule '(+ a b))]
(f 18 56))
74
Zak Wilson a écrit :
> So as it turns out, I was mistaken about it working. I had something
> that ran, but the results were nonsense. What I'm tr
Correction: it's
(let [x '(+ (* 1024 device-id) rave-id))
rfn (rulefn x)]
...)
that fails with "Can't eval locals".
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, s
So as it turns out, I was mistaken about it working. I had something
that ran, but the results were nonsense. What I'm trying now looks
like this:
(defmacro rulefn [r]
(let [er (eval r)]
`(fn [devid# raveid#]
(binding [device-id devid#
rave-id raveid#]
~er
On Jan 23, 1:47 pm, Zak Wilson wrote:
> And it's now working perfectly, producing a new generation every
> second. Now I actually have to tweak it to produce good results.
It's great that this is working for you. I tried the same approach in
a genetic programming project of my own, and I eventu
And it's now working perfectly, producing a new generation every
second. Now I actually have to tweak it to produce good results.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group,
Kevin, I don't know how I managed to not think of that, but it's
exactly what I was looking for.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegro
On Jan 23, 1:18 pm, Kevin Downey wrote:
> instead of using binding and eval, you can generate a (fn ) form, eval
> it, keep the result function stuffed away somewhere and apply it
> instead of calling eval all the time
Yeah, when I made this optimization to my code a couple weeks ago it
sped the
instead of using binding and eval, you can generate a (fn ) form, eval
it, keep the result function stuffed away somewhere and apply it
instead of calling eval all the time
On Fri, Jan 23, 2009 at 1:10 PM, Zak Wilson wrote:
>
> It does seem like a legitimate use for eval, at least at first glanc
It does seem like a legitimate use for eval, at least at first glance.
The biggest problem is that using eval this way is really slow when
each rule is being tested on hundreds of inputs.
Interesting alternative, Konrad. I can probably take advantage of the
fact that all of the functions I'm call
On Jan 23, 2009, at 16:20, Zak Wilson wrote:
> that appear in these lists and evaluate them as code. My current
> technique looks like this:
>
> (def a)
> (def b)
> (defn try-rule [r val-a val-b]
>(binding [a val-a
> b val-b]
> (eval r)))
>
> and an example call looks
Hi Zak,
I think this is a reasonable use of eval, since you're evaluating an
expression that is generated at run-time. The alternatives are messy.
-Stuart Sierra
On Jan 23, 10:20 am, Zak Wilson wrote:
> I'm trying my hand at genetic programming. (Full post about why and
> how, with code comi
21 matches
Mail list logo
