>If you only have one array, why bother with a node representing it? Why
not just have a function called (length) and another function called (get
__index__), which is defined as, I dunno, mod(abs(floor __index__), length
of array) ?
I see your point. That makes sense in terms of design. So the array itself
would reside inside the Problem instance.
>Here's why I'd use an ERC. If you're plugging real-valued equations into
__index_, you're going to be looking at nearly unreadable code. Anyway,
you're going to need terminal constants one way or the other, which means
ERCs. If you're going ERCs anyway, why not go the cleaner route and do ERCs
for your variables?
Are you suggesting that __index__ in this case is a variable that extends
ERC for its base class? So at some point in my tree there would be an
assignment operation to __index__?
Upon taking a step back, I'm not sure I've framed my problem properly. I
have to assume that my input will an array of variable length, and the code
should consider each item in the array before deciding whether or not to
select it. As a novice to GP, have I bit off more than I can chew? Are
there certain techniques I need to read more on like ADFs?