- Cost (
Cost_fcn
): const Matrix *series
-> pointer to the series for which a surrogate is generateddouble cost
-> current costvoid cost_transform (Matrix *)
-> initial transformation which is used for better calculation of costMatrix cost_invert () const
-> assigns to the input variable the inverse of the transformation performed above (to get the actual surrogate, not just a representation of it in a different form)double cost_update (octave_idx_type nn1, octave_idx_type nn2, double cmax, bool &accept)
-> perform quick update ofcost
(for a swap of elements under indexnn1
andnn2
) and decide if cost is smaller than maximumcost
(cmax
) if yes, accept newcost
and returntrue
otherwise reject newcost
and returnfalse
double cost_full()
-> performs a full calculation of thecost
, takes longer thancost_update()
- getters/setters for
cost
- Cool (
Cool_fcn
): double temp
-> holds the current temperaturedouble cool (double cost, bool accept, bool &end)
-> takes currentcost
,accept
which holds whether the lastcost_update()
was accepted or not and returns the newtemp
and sets flagend
to indicate if the simulated annealing is over- Permute (
Permute_fcn
): Matrix *series
-> holds the pointer to the series, and modifies the series only whenexch()
is calledvoid permute (octave_idx_type &n1, octave_idx_type &n2) const
-> generates two indexesn1
andn2
that can be used to calculateCost_fcn::cost_update()
void exch (octave_idx_type n1, octave_idx_type n2)
-> exchange element undern1
with element undern2
in theseries
Those are the methods I intend to have in the base/abstract classes which will be called by the Simulated Annealing runner code. I have not decided what that code should look like, but the current version seems to be working as well as the
I was also hoping to create a subclass of each of those abstract classes built to call GNU Octave code. This would allow the user to create their own functions without having to write anything in C++. However, this idea might not be practical for the following reasons:
randomize
program from TISEAN package.I was also hoping to create a subclass of each of those abstract classes built to call GNU Octave code. This would allow the user to create their own functions without having to write anything in C++. However, this idea might not be practical for the following reasons:
- The example of Simulated Annealing provided in the TISEAN package (ver. 3.0.1), takes about 0.7 seconds to run using only C++ code and performs on average 900,000 calls to
Cost_fcn::cost_update()
and calling a simple function in Octave that many times (using thefor
loop) took 16 seconds - I have trouble deciding how to neatly pass these functions/classes to
randomize
along with some parameters the user might want to include. I originally thought of usingclassdef
- the new keyword introduced in Octave 4.0.0. I hoped to create an abstract Octave class and then let anyone subclass it to create their own cost, cool and permute classes. The problem is thatclassdef
and all of the associated keywords are not documented, moreover according to Carnë Draug thehelp
function will not recognize this new type of Octave class. So even if all of the needed functionality was available in Octave I might not be able to document it for the user
If obstacle 2. can be overcome it might still be beneficial for the package to create this type of functionality, regardless of how long the code will execute.
This week I plan to refine the design of the abstract classes as well as port more of the cost function options from TISEAN.
[Update]: I modified the design a bit and updated this post to fit the new code.
This week I plan to refine the design of the abstract classes as well as port more of the cost function options from TISEAN.
[Update]: I modified the design a bit and updated this post to fit the new code.