Documentation/Modules/Interfaces: Unterschied zwischen den Versionen

Aus OpenDino
Wechseln zu: Navigation, Suche
 
Zeile 1: Zeile 1:
 
==Basics==
 
==Basics==
  
The basic element of each OpenDINO optimization or learning environment is still the <code>Module</code>. Each optimization problem, each optimization algorithm and each learning algorithm is a module. A class that is used as a module must implement the interface <code>org.opendino.core.modules.IModule</code> (see [[Documentation/IModule | IModule]]).
+
The basic element of each OpenDino optimization or learning environment is still the <code>Module</code>. Each optimization problem, each optimization algorithm and each learning algorithm is a module. A class that is used as a module must implement the interface <code>org.opendino.core.modules.IModule</code> (see [[Documentation/IModule | IModule]]).
  
The whole structure of modules in OpenDINO is based on interfaces. The reason for this is that classes that are used as <code>Modules</code> may be part of a class hierarchy and thus they cannot inherit from a basic module class.
+
The whole structure of modules in OpenDino is based on interfaces. The reason for this is that classes that are used as <code>Modules</code> may be part of a class hierarchy and thus they cannot inherit from a basic module class.
  
 
There are <code>Modules</code> that can be run, e.g. optimization algorithms. All these modules implement the interface <code>org.opendino.core.modules.IRunnable</code>.
 
There are <code>Modules</code> that can be run, e.g. optimization algorithms. All these modules implement the interface <code>org.opendino.core.modules.IRunnable</code>.

Aktuelle Version vom 19. März 2014, 23:06 Uhr

Basics

The basic element of each OpenDino optimization or learning environment is still the Module. Each optimization problem, each optimization algorithm and each learning algorithm is a module. A class that is used as a module must implement the interface org.opendino.core.modules.IModule (see IModule).

The whole structure of modules in OpenDino is based on interfaces. The reason for this is that classes that are used as Modules may be part of a class hierarchy and thus they cannot inherit from a basic module class.

There are Modules that can be run, e.g. optimization algorithms. All these modules implement the interface org.opendino.core.modules.IRunnable.

Each optimization setup consists of at least two linked Modules: a problem and an optimizer. The interfaces for these modules are org.opendino.core.modules.optimization.IEvaluable and IEvaluator, respecively. The corresponding pair for a learning task is org.opendino.core.modules.learning.IDataSource and IDataSink.

Modules can be linked between other modules. E.g. the protocoller is a Module that you can link between an optimizer and a problem. In such a case, all Modules except the optimizer must implement the interface Evaluable and all modules except the problem must implement the interface IEvaluator. This means that the modules form a chain that looks like this (here, two intermediate modules are shown):

              [IEvaluator]
                   |
       [IEvaluable and IEvaluator]
                   |
       [IEvaluable and IEvaluator]
                   |
              [IEvaluable]

where the topmost evaluator is the optimizer and the bottommost evaluable is the optimization problem. The meaning of this picture is that the optimizer produces points and sends them through the chain to the problem. The problem evaluates the points, assigning each point its objective value(s). These are read by the optimizer which then tries to create better points, etc. The same kind of interaction chain is possible for learners and data sources. But there, the information flow is mainly in unidirectional: from the data source to the data sink.

The Interfaces

IModule

This is the basic interface implemented by all modules. It contains methods for the initialisation and checking of the module and for the management of the options of the module.

IRunnable

This interfaces is implemented by all modules that can be run. When a module is run, it executes its optimization algorithm. In the future this could be any kind of algorithm. The interface contains methods to start and stop the execution of the module.

IEvaluable

Every module that represents an optimization problem implements the interface IEvaluable. This means that the module can evaluate a given solution. To that end, it looks at the design variables of a solution object it gets from an optimizer and sets the objective value(s) of that object accordingly.

If a module is linked before a problem module, it must implement IEvaluable and delegate the evaluation of the solutions to the problem module. Thus, the optmimizer doesn't know if the module right after it is the problem itself or an intermediate module, it just calls the evaluate method of its successor module.

IEvaluable contains methods to evaluate one solution or an array of solutions and a method to get the properties of the problem.

IEvaluator

A module that can call an evaluable to evaluate solutions implements the interface IEvaluator. Normally, an evaluator is an optimizer module, but any intermediate module between the optimizer and the problem must implement this interface as well. Otherwise, it wouldn't be able to call the problem to evaluate the solutions.

IEvaluator contains methods to get and set the references to the evaluables and to check if these links are OK.

IDataSource

A module that provides data. This can be a file reader, the protocoller, or other modules that can produce or store data. The getData() method is the most important one.

IDataSink

A module implementing this interface represents a learner. It is linked with a data source and processes the given data. Very different kinds of processing are possible. A data viewer can just display the data, a neural network can learn a function from the data or a statistics module can compute some statistics on the data etc.