Print

Print


Heya,
  Sorry for the late reply. Work can be annoying :P
  The problem I was trying to solve was how to programatically set the upper bounds of the training data array and then be able to access that information in the mutate method of my ERC. It works out well that that info is setup in the prototypical instance of the problem and doesn't change, so that I could call methods of said instance from within the mutator method via state.evaluator.p_problem. However, if I wanted to access dynamic data from a specific problem instance that DID change, I'd be SOL. Not sure how to crack that one, not that I need to right now.

Thanks again for your help!

-Mark

On Thu, Jun 6, 2019 at 5:47 PM Sean Luke <[log in to unmask]> wrote:
Wait, wait, wait.

state.evaluator.p_problem is a reference to the *prototypical* Problem.  This is the Problem which was loaded with setup(), but it's unused.  Instead it's cloned to create the actual Problems that are used during evaluation.

If these Problems share a pointer with the prototypical Problem to the data you're interested in, and assuming that data is considered constant, then you might be okay.  But before we said this for sure, I'm trying to figure out what you're doing.

I *think* your situation is this:

        1. The prototypical ERC is setup
        2. THEN the prototypical Problem is setup
        3. Then we build an GPIndividual that has some ERCs in it (cloned from the prototypical ERC)
        4. Then we assess this GPIndividual by passing it to a Problem (cloned from the prototypical Problem)
        5. You want the ERCs to have access to data in the prototypical Problem.

Is this correct?

If so, why not just access the data in their own Problem instance?  Each GPNode, thus each ERC, has a method called eval(...) which
is called when the ERC is run.  That method is passed the Problem instance.  You can see ec/app/regression/func/RegERC.java for an example.  Why not just access the problem there?  It likely shares the table you want with your prototypical Problem, right?

Sean


> On Jun 6, 2019, at 3:44 PM, Mark Parker <[log in to unmask]> wrote:
>
> Eric,
>   Thanks! I KNEW that EvolutionState had to have a reference to the problem somewhere, I just couldn't figure out where.
>   There are many levels to this framework.
>   I'll go try that and see what happens.
>
> -Mark
>
> On Thu, Jun 6, 2019 at 2:40 PM Eric 'Siggy' Scott <[log in to unmask]> wrote:
> Hi Mark,
>
> I haven't work with ERCs, but I expect that you can solve your problem by reaching into the EvolutionState object:
>
> The EvolutionState has a reference to your Problem: state.evaluator.p_problem.  So you don't need to create custom EvolutionState fields: any method that has a reference to state can access your problem and the data associated with it.  We do this, for example, for TSP: ec.app.tsp.TSPProblem dynamically loads a description of a TSP problem from a file, and other parts of ECJ access it by making calls to state.evaluator.p_problem.
>
> Thanks,
> Eric
>
> On Thu, Jun 6, 2019 at 12:25 PM Mark Parker <[log in to unmask]> wrote:
> Hi all,
>   Hoping someone can help me with this one. I'm finding passing data between classes troublesome. What I'm trying to do is have an ERC that has indices that map to a table cell built up by Problem.setup from reading the training data.
>   The issue is that I want the max indices to be dynamic and determined during the reading of the training data file during Problem setup. I can't, however, figure out how to get that info from the Problem class to the ERC class so it can mutate without running into out of bounds issues.
>   I've tried setting some custom parameters during Problem.setup but that class gets instantiated after my ERC class so my ERC class can't find said parameters cause they haven't been set yet.
>   The only thing I can think of, which I don't really want to do, is to subclass SimpleEvolutionState and put in some fields and methods that Problem.setup can call to set, and MyERC can call to get.
>   This all feels very clunky and I feel like there's got to be a better way.
>
> Any help is appreciated.
>
> Thanks,
>
> -Mark
>
>
> --
>
> Doctoral Candidate, George Mason University
> http://mason.gmu.edu/~escott8/