fema-team team mailing list archive

[Themiya Jayasinghe <themiya.jayasinghe@xxxxxxxxx>]

Hi,

Please ignore the getOptions(...) method in
fema::algorithm::AlgorithmOptions. It's not being used by anything except
the unit test.

The way it is being done at the moment is that I convert all the values and
store them in public members of WuJi07Options ( please seee
WuJi07Options.readFromStream(...) ). In my Algorithm class (WuJi07Algorithm)
I have a
private member of type WuJi07Options.

I think the best option would be to put options common to all algorithms
(e.g: maxEvolutionCount) in fema::algorithm::Options and problems common to
MOO algorithms in MOOOptions and problems specific to PAES in PAESOptions.
However, the implementors of the MOOOptions / PAESOptions will need to call
the super classes readFromStream(...) method to set the common options. e.g:

class fema::algorithm::Options {
public:

virtual void readFromStream(stream) {

 //read common options

}

}

class fema::algorithm::moo::MOOOptions : public fema::algorithm::Options {

typedef fema::algorithm::Options _super;

public:

virtual void readFromStream(stream) {

_super.readFromStream(stream);

//read options specific to MOO

}

}

class fema::algorithm::moo::paes::PAESOptions : public
fema::algorithm::MOOOptions {

typedef fema::algorithm::Options _super;

public:

virtual void readFromStream(stream) {

_super.readFromStream(stream);

//read options specific to paes
this->maxArchiveSize = ...;

}

If we want to seperate the reading of options from the Options classes,  we
need another heirarchy for OptionsReader
classes. (OptionsReader,  MOOOptionsReader, PAESOptionsReader). Then the
Options classes will just have public  members for storing the different
options

struct fema::algorthm::Options {

size_t maxEvolutionCount;
...

}
 ...

struct fema::algorithm::moo::paes::PAESOptions : public
fema::algorithm::moo::MOOOptions {

size_t maxArchiveSize;

}

Then in your PAESAlgorithm class you would have;

class PAESAlgorithm : .... {

public;

const bool isEnd() { return _options->maxEvolutionCount >=
this->_evolutionCount; }

void evolve() {


....
if (_options->maxArchiveSize < this->_archive.size()) {

//add to archive

}

...

}

private:

shared_ptr<PAESOptions>  _options;

}

If we want to support multiple file formats for the options.in.dat file then
we would need to extend the necessary OptionsReader classes. I think we
should standardise the file format used for options.in.dat files so that we
can reuse as much code as possible. (I went with the name : value format
because I thought it is easier than parsing XML. But I'm open to other
formats)


In regards to the Application class loading the options, how would it know
to create the appropriate type of  OptionsReader and Options instances ?
That's why I put it in the factory.

Or did you mean create the correct OptionsReader in the main.cpp and read
the Options from that ?

-jt

---------- Forwarded message ----------
From: James Newell <jameslnewell@xxxxxxxxx>
Date: Wed, Oct 12, 2011 at 3:08 PM
Subject: Merged our branches
To: Themiya Jayasinghe <themiya.jayasinghe@xxxxxxxxx>


Hi JT,

Just merged our branches and have a few comments/questions…

Other…
Probably doesn't really matter about the .project files in our app folders
(maybe we can ignore them) as we probably won't be loading each others apps
in eclipse - if we want to run it its easier to bjam from the console… but
doesn't matter that you've done it… just to save you time.

Options…

The naming of the options class and the methods that it contains is a little
confusing… Could we have the options class encapsulate a Map<string, string>
with accessors something like

Options
string getString(string name, int defaultValue);
int getInteger(string name, int defaultValue);

PAESOptions
int getMaxEvolutionCount() { return getInteger("max_evolution_count",
10000);  }
int getMaxArchiveSize() { return getInteger("max_archive_size", 100); }

OptionsReader
Options read();

JTFormattedFileOptionsReader
JTFormattedFileOptionsReader(string filename);
 Options read();  => which reads options from a file in the format
"<option_name> : <option_value>"

Then we don't *have* to extend AlgorithmOptions for each of our algorithms -
we can just take a generic instance of the class.
But if one desired we could extend AlgorithmOptions with methods like
getMaxEvolutionCount() which just calls the getInteger method.
This will save lots of boilerplate code converting options from a string
value to the desired type - something that everyone will be doing.

Could we have an AlgorithmOptionsReader (may be rename to Options and
OptionsReader??) instead of the read methods within the
current AlgorithmOptions class. This way there is the possibility of options
being read from different sources and formats.
Instead of each writing our own option readers there should be a common
reader (e.g. JTFormattedFileOptionsReader and not WujiOptionsReader) that
the Application class can use for all algorithms.

Can we have the Application responsible from loading the options (from file)
and have Factory::createAlgorithm(Instance instance, Options options)
instead?

Hope thats clear. Let me know what you think.

James