ECJ-INTEREST-L Archives

December 2005

ECJ-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Date:
Wed, 14 Dec 2005 15:21:49 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (119 lines)
The paper you pointed to introduces some complications.  The example
he provides is:

(accum (elt-var over vector)
        (result-var from initial)
   body)

For example:

(accum (R1 over V2)
        (R2 from –infinity)
   (if (< R1 R2) R2 R1))

So what's so hard about this?  The problem is that it defines two
variables, R1 and R2.  Let's assume those variables are part of the
function set.  Then what if you nest your accums?  I'd imagine that
the R1/R2 would shadow the outer R1/R2.  So what if you want, in the
inner nested accum, to access the outer variables?  The only way to
do this would be to have two MORE variables (R3/R4), and so on.

Thus you could be looking at an infinite-sized function set.

Obviously if you just want iterators and don't care about full
nestedness, then it's not an issue.  But in that case you might as
well define your accumulator as

(accum _vector_ _initial_result_ _body_)

In the _body_ you then have access to two more variables: accum-
result (R2) and accum-elt (R1).  I suppose this could be turned into
an ADM-ish sort of thing, like this:

(accum _vector_ _initial_result_)

Which then calls another tree which has access to the accum-result
and accum-elt variables (which get updated each iteration).

Sean

On Dec 14, 2005, at 3:01 PM, George Coles wrote:

> The subtree that is evaluated upon each iteration needs to have access
> to locally scoped data, for example, the index variable of the loop.
> This seems to fit with macros.
>
> Kirshenbaum 2001 discusses this:
> http://www.hpl.hp.com/techreports/2001/HPL-2001-327.pdf
>
>
> Sean Luke wrote:
>
>> ADMs are used identically to ADFs: but they evaluate child trees
>> repeatedly and on-the-fly as called for in the remote tree.  This
>> emulates one essential difference between a macro and a function in
>> Lisp.
>>
>> That being said, I don't think an ADM is exactly what you're looking
>> for.  Why not just write a nonterminal node which does a loop on its
>> kids like below?
>>
>> Sean
>>
>> On Dec 14, 2005, at 2:26 PM, George Coles wrote:
>>
>>> Thanks for the tip. I have never used ADMs, for some reason I find
>>> them
>>> confusing - for example, should I call super.eval within the
>>> evaluate
>>> method?
>>>
>>> Sean Luke wrote:
>>>
>>>> It depends on how you want to do loops.  What do you mean by
>>>> automatically-defined-loops exactly?  It seems to me that the
>>>> straightforward way is to just have a loop macro as one of your
>>>> nodes, whose eval() method looks something like this:
>>>>
>>>>     result = empty
>>>>     n = eval first child
>>>>     loop n times or until MAX_ALLOWED_LOOPS:
>>>>         result = eval second child
>>>>     return result
>>>>
>>>> Or you could have a while loop along these lines:
>>>>
>>>>     count = 0;
>>>>     loop up to MAX_ALLOWED_LOOPS:
>>>>         n = eval first child
>>>>         if n == true then eval second child and return
>>>>     return empty
>>>>
>>>> Sean
>>>>
>>>> On Dec 7, 2005, at 7:55 PM, George Coles wrote:
>>>>
>>>>> Hi,
>>>>>    Can anyone point me to an example of automatically defined
>>>>> loops
>>>>> that works with tree-based GP? Has anyone implemented loops in
>>>>> ECJ?
>>>>> I am
>>>>> contemplating beginning to add this feature to my copy of ECJ
>>>>> and it
>>>>> seems a bit daunting. Could the ADF stack be leveraged somehow
>>>>> to do
>>>>> this? As an aside, it seems odd that iteration and recursion
>>>>> are not
>>>>> more popular as a topic of discussion. I expect that I will really
>>>>> need
>>>>> iteration, at least, in my project, and I would think that many
>>>>> people
>>>>> would find it very valuable.
>>>>>
>>>>> Thanks
>>>>> George Coles
>>>>>
>>>>
>>

ATOM RSS1 RSS2