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

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.
>> class can't find a terminal type-compatable with number
>> java.lang.StackOverflowError
>> at
>> at
>> ....
>> 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)