adil raja wrote:
> Hi,
>    I presume that you are talking about converting the tree to a java source file and then compiling it and then executing it?
Basically yes. Albeit you can do this using runtime compilation where 
you're just passing a string to the java compiler ..
>  This surely is going to be slow. And then, ECJ is already in java. So what would this step save. 
(warning: My knowledge of hotspot and java optimization altogether very 
limited!). I presume that the optimizer cannot get much past one 
function boundary. So in order to evaluate and individual that's 
represented by a tree with say 10 nodes, you have to do quite a lot of 
computation, intermediate function calls etc. But then in symb 
regression, the actual individual is just a formula and except for the 
math function calls (like Math.exp), you don't have to do anything like 
tree traversal etc. So my thought was that evaluating a compiled string 
like:
"""
class RuntimeEvalMe implements RuntimeEval {
double eval(int x, int y, int z) {
    return x * x - Math.cos(z) + 123.;
}
"""
could be quite fast. Given my problem settings (10^3 evaluations of the 
same evalMe function with different parameters), this could actually 
outweigh the cost of compiling.

> Symbolic regression can be made fast by opting for vector processing/evaluation by the interpreter. Much further improvements may be made by employing subtree caching. There is a paper by Maarten Keijzer that explains on this.
>   
I am pretty sure subtree caching is effective when a single instance of 
"eval" is not called many times. I do not wish do dig into this any 
deeper, ecj is actually reasonably fast for what I need. My idea just 
looks reasonably easy to implement and could boost the computation speed 
quite noticeably (for my specific symb reg problem) if I needed too.

Thanks a lot for your comments,

Ondrej
> Regards,
> Adil Raja
>
>
>
> ----- Original Message ----
> From: Ondrej Pacovsky <[log in to unmask]>
> To: [log in to unmask]
> Sent: Saturday, September 27, 2008 3:29:43 AM
> Subject: runtime complilation for expensive eval ?
>
> Hi,
>
> I was wondering whether someone tried converting the GP individual to
> java (or other) code (perhaps by the ECJ to Java converter) and
> compiling it before actually running the evaluation. This is of course
> quite slow, but for symbolic regression on many training values could be
> interesting. Thinking of 10^3 and more evals per individual per generation.
>
> -- Ondrej
>
>
>
>       
>