About the algorithm-problem relationship

I’m opening this issue to start the discussion about the algorithm-problem relationship.

My point of view is the following. An Algorithm in jMetal is a metaheuristic, so it is intended to solve a given problem, so I included the relationship “Algorithm solves Problem” in the class diagram.

On the other hand, the interface Algorithm does not make any reference to problems:

public interface Algorithm<R> extends Runnable, Serializable {
  public void run() ;
  public R getResult() ;
}

However, if we deep into the class hierarchy, all the Builder classes to configure and instantiate algorithms have one mandatory argument: the problem (I discussed about this with Matthieu in another issue), so the relationship Algorithm-Problem is in the code.

I agree that my view is very biased, because the concepts are clear to me.

We have several ways to proceed:

• Do nothing
• Consider renaming Algorithm as `Metaheuristic´, as in the former versions of jMetal. This vay, the relationship is implicit given the definition of what a metaheuristic is.
• Change the Algorithm interface. For example, a void setProblemToSolve() could be added, or the run() method could be changed to solve(Problem). Here, I like the run() method because it allows to run the algorithm in a thread, as Matthie suggested.

This discussion also applies to the relationship “Algorithm uses Operators”.

I’m open to suggestions about the most convenient way to proceed.

[matthieu-vergne]

Considering that a significant part of the discussion was about parameters of the algorithm which need to be set at various times depending on the context, would you be interested to have setter/getters for each parameter? The idea is to be able to set them whenever we need/want before the execution of the Algorithm. If the Algorithm is coded for it, it is also possible to change the parameters during the run, like required in #185.

[matthieu-vergne]

I am currently working on the experiment architecture. It is well advanced, but not finished yet (I don’t have a full experiment ready yet). I will present it in #135 when it will be complete, but so far it does not depend on the dependency between algorithms and problems (they can be completely independent or completely coupled, it works anyway) because it requires only the algorithm (the problem can be used in any way, the experiment architecture is oblivious to it). This way, it offers a lot of flexibility, so we can use it already with the current jMetal architecture, and even if we revise the dependency between algorithms and problems it should not impact the architecture of experiments.