[libkorigin Index] [libkorigin Heirarchy]
Abstract Base Class for Generic Fitters More...
#include </home/mh/korigin/korigin/doc/tmp/fitter.h>
Abstract Base Class for Generic Fitters. This is as generic as possible, just an interface to (hopefully) *any* kind of fitter.
The basic idea is the following. What do fitter have in common?
They all take input data and create output data, in form of columns of numbers. This has been taken into account by providing the functions setInputColumns() and setOutputColumns().
The number of columns they take as input and fill as output, however, varies, as does the meaning of the columns. In respect to this, the functions getInputColumnCount(), getOutputColumnCount(), getInputColumnName(), and getOutputColumnName() have been made pure virtual: each fitter must implement them for itself.
Every fitter might offer some specific options, which can be queried in some dialogs as well as stored/retrieved to/from a config file. to offer this functionality, the pure virtual functions execOptionsDialog(), saveSettings(), and loadSettings() have been introducted.
Finally, every fitter must actually *do* something, namely a fit. Therefore, a pure virtual function, fit() has been declared, and each fit must implement it.
For an example for a fit, see the @ref LinearRegression fitter.
Default constructor. Just initializes some pointers to zero.
Destructor - just to ensure that it is virtual. Fitters are destroyed by deleting Fitter pointers. Since these actually point to concrete (derived) fitters which may have their own destructors, the destructor of the base class must be declared virtual, even if it doesn't do anything.
[pure virtual] Return the concrete fitter's name.
Pop up the fitter's options dialog box. The (derived) concrete fitter must implement it's own Options dialog, of course. That's why this is pure virtual.
[pure virtual] Returns the number of columns a fitter takes for input. A linear regression fitter would take two columns, namely x and y, for input.
[pure virtual] Returns the number of columns a fitter fills with itsoutput.
A linear regression fitter would fill one column, y_linear, as output. Note that the caller has to create those columns! They are _not_ created by the Fitter!
[pure virtual] Returns the symbolic name of the ith input column thefitter takes.
For a linear regression fitter, this would be "X" for i=0 and "Y" for i=1.
[pure virtual] Returns the symbolic name of the ith output column thefitter fills.
For a linear regression fitter, this would be "YLinear" for i=0.
[pure virtual] Defines what columns the fitter should take for input. The array of columns passed to this function is taken as input data for the fitter. For an interpretation of the ith entry of the array, check the description returned by getInputColumnName().
The caller is responsible for deleting the columns! Not the fit!
col_array | the array of columns to be taken as input data. |
[pure virtual] Defines the columns to be filled by the fitter. The columns passed to this functions will be taken as output buffer, i.e. the fitter will fill them with the results of the fit. A linear regression fitter would fill its single output column with the fitted y values for the appropriate x (input) value. However, a non-linear fitter would most likely also fill a column with its own x values, since the input x values might be too coarse to make sense with fitted y values. It is important to understand that the columns in the output buffer are not necessarily of the same length as the input columns. A fitter might decide that it needs a finer x stepwidth and create a grid with dx=0.01 whereas the input columns have dx=0.1. With self-expanding columns, this is a plug to implement.
In analogy with setInputColumns(), the columns handed to this function must already exist (though they might be empty). Their meaning can be obtained by getOutputColumnName().
The caller is responsible for deleting the columns! Not the fit!
col_array | the array of columns to be filled by the fitter. |
[pure virtual] The actual fitting function. This is the core of the fitter. In here, the actual fitting algorithm is implemented. Or, as a matter of fact, the derived concrete fitter must implement it here. Please do _not_ do any dialogs here! This function might get called as a thread of its own later. (Currently, it blocks the program.)
[pure virtual] Save fitter-specific settings to the configuration file. If your fitter has some specific settings, your implementation of this function's got the chance to store them in Korigins config file. A neuronal net fitter might save the (maximum) number of nodes; an iterative fitter might save some epsilons. Of course, the implementation of this function must match loadSettings().
conf | pointer to Korigins KConfig instance. |
[pure virtual] Load fitter-specific settings from the configurationfile.
If your fitter has some specific settings, your implementation of this function's got the chance to restore them from Korigins config file. A neuronal net fitter might load the (maximum) number of nodes; an iterative fitter might retrieve some epsilons. Of course, the implementation of this function must match saveSettings().
conf | pointer to Korigins KConfig instance. |
Main menu entry for the Fitters. This function builds the main menu entry "Fit".
Options menu entry for the Fitters. This function builds the menu entry "Options|Fitter".
Input data for the fitter. This array, filled by the caller and used by the fitter, contains the input data for the fit. The implementation of fit() will read it. Note that it must be deleted by the caller, not by the destructor.
Output buffer for the fitter. This array, provided by the caller, is filled during the fit(). Note that it must be deleted by the caller, not by the destructor!
| Kdoc |