Package ec

Class Problem

java.lang.Object
ec.Problem
All Implemented Interfaces:
Prototype, Setup, Serializable, Cloneable
Direct Known Subclasses:
GEProblem, GPProblem, MasterProblem, MetaProblem
public abstract class Problem extends Object implements Prototype
Problem is a prototype which defines the problem against which we will evaluate individuals in a population.

Since Problems are Prototypes, you should expect a new Problem class to be cloned and used, on a per-thread basis, for the evolution of each chunk of individuals in a new population. If you for some reason need global Problem information, you will have to provide it statically, or copy pointers over during the clone() process (there is likely only one Problem prototype, depending on the Evaluator class used).

Note that Problem does not implement a specific evaluation method. Your particular Problem subclass will need to implement a some kind of Problem Form (for example, SimpleProblemForm) appropriate to the kind of evaluation being performed on the Problem. These Problem Forms will provide the evaluation methods necessary.

Problem forms will define some kind of evaluation method. This method may be called in one of two ways by the Evaluator.

  • The evaluation is called for a series of individuals. This is the old approach, and it means that each individual must be evaluated and modified as specified by the Problem Form during the evaluation call.
  • prepareToEvaluate is called, then a series of individuals is evaluated, and then finishEvaluating is called. This is the new approach, and in this case the Problem is free to delay evaluating and modifying the individuals until finishEvaluating has been called. The Problem may perfectly well evaluate and modify the individuals during each evaluation call if it likes. It's just given this additional option.

Problems should be prepared for both of the above situations. The easiest way to handle it is to simply evaluate each individual as his evaluate(...) method is called, and do nothing during prepareToEvaluate or finishEvaluating. That should be true for the vast majority of Problem types.

See Also:

  • Field Details

  • Constructor Details

    • Problem

      public Problem()

  • Method Details

    • defaultBase

      public Parameter defaultBase()
      Here's a nice default base for you -- you can change it if you like
      Specified by:
      defaultBase in interface Prototype

    • setup

      public void setup(EvolutionState state, Parameter base)
      Description copied from interface: Prototype
      Sets up the object by reading it from the parameters stored in state, built off of the parameter base base. If an ancestor implements this method, be sure to call super.setup(state,base); before you do anything else.

      For prototypes, setup(...) is typically called once for the prototype instance; cloned instances do not receive the setup(...) call. setup(...) may be called more than once; the only guarantee is that it will get called at least once on an instance or some "parent" object from which it was ultimately cloned.

      Specified by:
      setup in interface Prototype
      Specified by:
      setup in interface Setup

    • clone

      public Object clone()
      Description copied from interface: Prototype
      Creates a new individual cloned from a prototype, and suitable to begin use in its own evolutionary context.

      Typically this should be a full "deep" clone. However, you may share certain elements with other objects rather than clone hem, depending on the situation:

      • If you hold objects which are shared with other instances, don't clone them.
      • If you hold objects which must be unique, clone them.
      • If you hold objects which were given to you as a gesture of kindness, and aren't owned by you, you probably shouldn't clone them.
      • DON'T attempt to clone: Singletons, Cliques, or Populations, or Subpopulation.
      • Arrays are not cloned automatically; you may need to clone an array if you're not sharing it with other instances. Arrays have the nice feature of being copyable by calling clone() on them.

      Implementations.

      • If no ancestor of yours implements clone(), and you have no need to do clone deeply, and you are abstract, then you should not declare clone().
      • If no ancestor of yours implements clone(), and you have no need to do clone deeply, and you are not abstract, then you should implement it as follows: 

         public Object clone() 
     {
     try
         { 
         return super.clone();
         }
     catch ((CloneNotSupportedException e)
         { throw new InternalError(); } // never happens
     }
      • If no ancestor of yours implements clone(), but you need to deep-clone some things, then you should implement it as follows: 

         public Object clone() 
     {
     try
         { 
         MyObject myobj = (MyObject) (super.clone());

         // put your deep-cloning code here...
         }
     catch ((CloneNotSupportedException e)
         { throw new InternalError(); } // never happens
     return myobj;
     }
      • If an ancestor has implemented clone(), and you also need to deep clone some things, then you should implement it as follows: 

         public Object clone() 
     { 
     MyObject myobj = (MyObject) (super.clone());

     // put your deep-cloning code here...

     return myobj;
     }
      Specified by:
      clone in interface Prototype
      Overrides:
      clone in class Object

    • prepareToEvaluate

      public void prepareToEvaluate(EvolutionState state, int threadnum)
      May be called by the Evaluator prior to a series of individuals to evaluate, and then ended with a finishEvaluating(...). If this is the case then the Problem is free to delay modifying the individuals or their fitnesses until at finishEvaluating(...). If no prepareToEvaluate(...) is called prior to evaluation, the Problem must complete its modification of the individuals and their fitnesses as they are evaluated as stipulated in the relevant evaluate(...) documentation for SimpleProblemForm or GroupedProblemForm. The default method does nothing. Note that prepareToEvaluate() can be called *multiple times* prior to finishEvaluating() being called -- in this case, the subsequent calls may be ignored.

    • finishEvaluating

      public void finishEvaluating(EvolutionState state, int threadnum)
      Will be called by the Evaluator after prepareToEvaluate(...) is called and then a series of individuals are evaluated. However individuals may be evaluated without prepareToEvaluate or finishEvaluating being called at all. See the documentation for prepareToEvaluate for more information. The default method does nothing.

    • initializeContacts

      public void initializeContacts(EvolutionState state)
      Called to set up remote evaluation network contacts when the run is started. By default does nothing.

    • reinitializeContacts

      public void reinitializeContacts(EvolutionState state)
      Called to reinitialize remote evaluation network contacts when the run is restarted from checkpoint. By default does nothing.

    • closeContacts

      public void closeContacts(EvolutionState state, int result)
      Called to shut down remote evaluation network contacts when the run is completed. By default does nothing.

    • canEvaluate

      public boolean canEvaluate()
      Asynchronous Steady-State EC only: Returns true if the problem is ready to evaluate. In most cases, the default is true.

    • describe

      public void describe(EvolutionState state, Individual ind, int subpopulation, int threadnum, int log)
      Part of SimpleProblemForm. Included here so you don't have to write the default version, which usually does nothing.

    • describe

      public final void describe(Individual ind, EvolutionState state, int subpopulation, int threadnum, int log, int verbosity)

    • sendAdditionalData

      public void sendAdditionalData(EvolutionState state, DataOutputStream dataOut)
      This method is called from the SlaveMonitor's accept() thread to optionally send additional data to the Slave via the dataOut stream. By default it does nothing. If you override this you must also override (and use) receiveAdditionalData() and transferAdditionalData().

    • receiveAdditionalData

      public void receiveAdditionalData(EvolutionState state, DataInputStream dataIn)
      This method is called on a Problem by the Slave. You should use this method to store away received data via the dataIn stream for later transferring to the current EvolutionState via the transferAdditionalData method. You should NOT expect this Problem to be used for by the Slave for evolution (though it might). By default this method does nothing, which is the usual situation. The EvolutionState is provided solely for you to be able to output warnings and errors: do not rely on it for any other purpose (including access of the random number generator or storing any data).

    • transferAdditionalData

      public void transferAdditionalData(EvolutionState state)
      This method is called by a Slave to transfer data previously loaded via receiveAdditionalData() to a running EvolutionState at the beginning of evolution. It may be called multiple times if multiple EvolutionStates are created. By default this method does nothing, which is the usual situation.

    • isGroupedProblem

      public boolean isGroupedProblem()
      Returns true if this method is meant to be a grouped problem. You should not override this method: by default it simply returns (this instanceof GroupedProblemForm), but some wrapper problems override it to query their underlying Problems. The purpose of this method is to enable objects to dynamically indicate that they support GroupedProblemForm (perhaps they are a wrapper object around an underlying object which might or might not support it).