fema-team team mailing list archive

[James Newell <jameslnewell@xxxxxxxxx>]

On 13/10/2011, at 11:37 AM, Themiya Jayasinghe wrote:

> Hi James,
> 
> 1. The DefaultOptions class will contain a protected member of type Options ?

There's two ways DefaultOptions could decorate Options…

1) Storing the Options class as a (protected) member variable of DefaultOptions and accessing the required option e.g. Options.getType(name, default) on demand e.g. DefaultOptions.getMaxIterationCount()

OR

2) In the DefaultOptions constructor pulling the options out of the Options class and setting local member variables e.g. DefaultOptions._maxIterationCount - this way is probably better for the performance of our algorithms if DefaultOptions.getMaxIterationCount() is going to be frequently throughout the algorithm

> 
> 2. How do we handle unsigned types ? Do we need things like Options.getUnsignedInteger(…) 

Yep using getType(name, default) methods… We'd make one for all the types commonly used…

Doing so abstracts us from changing atoi() to boost::lexical_cast to something else in the future so we don't have to modify every OptionsDecorator class in the future.

> 
> 3  In the DefaultOptions class, store the maxIterationCount in a private member like how you did for maxArchiveSize in PAESOptions. 
> ( Otherwise you would need to pass the default value to _options.getInteger(...) in getMaxIterationCount() )
> 
> i.e. change 
> 
> <<class>> DefaultOptions
> DefaultOptions(Options options) 
> int getMaxIterationCount() { _options.getInteger("max_iteration_count", ???); }
> 
> to 
> 
> <<class>> DefaultOptions
> size_t _maxIterationCount
> DefaultOptions(Options options) : _options(options) {
> _maxIterationCount = _options->getUnsignedInteger("max_iteration_count", 10000000);
> }
> size_t getMaxIterationCount() { return _maxIterationCount; }

Yep either way… Where the default value is defined isn't an issue (either in the getter or in the constructor) as long as it is only defined in a single place.

This way as stated above would be better for performance. This way also allow us to put setters on the class to override default values programatically (e.g. not loaded from options.in.dat) for testing purposes.

> 
> 4 . Maybe rename Options to OptionsContainer or something like that ? Also, rename DefaultOptions to Options ?

Yeah probably need to think through the names better. Open to suggestions! <<class>> Options, <<interface>> OptionsDecorator, <<class>> PAESOptionsDecorator

> 5 . hierarchies


Are you still thinking that we should have hierarchies of decorators e.g. Options[Decorator], MOOOptions[Decorator], PAESOptions[Decorator]??? If so how were you thinking the PAESOptions[Decorator] could override the default maxIterationCount with its own more appropriate value?

I think your/our goal for this hierarchy is having consistency of option names for common options between algorithms… Whilst I agree this is an excellent goal I don't think all algorithms will have a common set of options outside maxIterationCount and algorithms need to be able to specify their own default values.

So if we do still decide to have hierarchies they should be hierarchies  of interfaces that algorithm implementors can choose to implement to provide a common interface.

> 
> -jt
> 
> P.S. Will you be coming to Uni today or tomorrow ?

I can make it in at some stage tomorrow. I have to confirm the time for another meeting but will let you know. I'm leaving for my Mother in Law's 50th about 3 in the arvo so may not be there for heaps long.

We need to get a list of things we have left to do and priorities so we can divvy the project up and get people working on stuff now. Since the Client is effectively working and you know the Server side of things better than anyone else can you start working on it ASAP (getting options sent to the algorithm to use multiple LS strategies etc isn't so important as getting the work generator creating islands and work units at this moment!). I'd like to do any further changes on the Client so you can focus on starting the Server. Is that OK? I'm happy to take on board whatever constness, RAII or other refactorings you were hoping to get done.

> 
> 
>