Print

Print


Hi, Sean.

Thanks for answering.

I understand your suggestion, but it is not a 'logical problem'. I'm
using GP to perform operations on vectors (terminals). There are many
operators that return double, but in fact, it is not possible an
individual/tree with only one terminal node (root) since there is none
returning a double.

But I believe that it will be easier if I include a terminal node as
an operator over two vectors (for example, the norm of them). Then
there will always be a terminal node to be used.

Best regards
Márcio


--------
Prof. Márcio Porto Basgalupp
Instituto de Ciência e Tecnologia (ICT)
Universidade Federal de São Paulo (UNIFESP)


On Wed, Dec 20, 2017 at 3:26 PM, Sean Luke <[log in to unmask]> wrote:
> Lots of tree-building algorithms need to be able to fill slots at any time with a terminal node.  But if you don't have any terminal node which is type-compatible with the slot, ECJ has to fill it with a nonterminal node, thereby extending the tree.  That's not great.  But there's another problem: if it is 100% likely, or highly likely, that a nonterminal will in turn cause this problem recursively (because it also has a slot of that type), ECJ will never be able to fill all of the slots before it runs out of stack space.
>
> If you are careful with your nonterminal function set you can get around this, but I would strongly urge you instead to allow terminal nodes with the given data type.
>
> Sean
>
> On Dec 19, 2016, at 9:01 AM, Márcio Basgalupp <[log in to unmask]> wrote:
>
>> Dear all,
>>
>> I'm using a constrained-based GP to evolve functions for a problem I have. My individual must return a double. However, in my problem there is not terminal node that returns a double. If I don't use a terminal that returns a double, I get the following warning (followed by an error).
>>
>> A GPNodeBuilder has been requested at least once to generate a one-node tree with a return value type-compatable with a certain type; but there is no TERMINAL which is type-compatable in this way.  As a result, the algorithm was forced to use a NON-TERMINAL, making the tree larger than requested, and exposing more child slots to fill, which if not carefully considered, could recursively repeat this problem and eventually fill all memory.
>>
>> ONCE-ONLY WARNING:
>>
>> class ec.gp.koza.FullBuilder can't find a terminal type-compatable with number
>> java.lang.StackOverflowError
>> at ec.gp.GPNodeBuilder.warnAboutNoTerminalWithType(GPNodeBuilder.java:238)
>> at ec.gp.koza.KozaBuilder.fullNode(KozaBuilder.java:117)
>> ....
>> recursively
>> ...
>>
>> I would like to understand at this point, since I have a lot of non-terminal nodes that return a double. Is there a way to avoid this problem even without using a terminal node that returns a double? If ECJ doesn't present this problem if I have a terminal node returning a double (ECJ chooses this terminal node as root), it could chose one of many non-terminal nodes as the root node. Is there any way to do that?
>>
>> Best,
>> Márcio
>>
>> --------
>> Prof. Dr. Márcio Porto Basgalupp
>> Instituto de Ciência e Tecnologia (ICT)
>> Universidade Federal de São Paulo (UNIFESP)
>> Tel: +55 12 3924-9500 (r: 9762)