January 2006


Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
George Coles <[log in to unmask]>
Reply To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Tue, 24 Jan 2006 17:21:10 -0500
text/plain (65 lines)
     I would recommend using the params database object in some fashion, 
it seems to be exactly meant for the purpose you are describing -- 
collecting user-configurable data into an easily traversed and 
manipulated container. just my $.02 EU

Eric Pascual wrote:

> Thanks George for your quick reply,
>>      I am also an ECJ newbie, but it can't hurt to comment on your 
>> email. It always makes me feel better when people respond to me, even 
>> when they are wrong :).
> I agree :-)
>> I think that item 1/ is sensible. main() is not that difficult to 
>> re-implement, especialy if you are willing to do basically cut and 
>> paste from main() into the new webMain or whatever you call it. 
> It was my conclusion. In fact, I have put in the doPost what is more 
> or less done in Evolve.main (simplified a bit, since I don't need 
> restart from checkpoint)
>> I do not understand very well what you mean in item 2/. By end-users 
>> input do you mean parameters such as those that appear in the various 
>> params files? 
> End-user parameters is the problem specific inputs which are entered 
> in   form by the user, and describing the context in which he wants to 
> find a solution. To be a bit more precise, they are for instance the 
> dimensions of the piece to be processed by the system we are trying to 
> configure with the GA. These parameters are conveyed by the Web 
> container in the parameters of the Web request.
> It would be possible to prgramatically store them in the ACJ parameter 
> database, but I don't see a real interest in doing this. My idea was 
> to store them in the EvolutionState.statics which seems to be there to 
> make app specific data available to the various objects involved in 
> the process.
>> As for finding the fitest individual, is you look at 
>> SimpleStatistics.finalStatistics(), for example, you will see that 
>> the best_of_run array is where the best individuals are contained. It 
>> should be fairly straightforward to access that member variable at 
>> the end of the run, since it is public. I have not looked at other 
>> implementations of Statistics, but I am pretty sure you will find it 
>> similarly easy to locate the best individuals such as each Statistics 
>> subclass considers them to be.
> OK. That's the way I understood the philosophy of the system. Seems 
> that we are at least to share the same vision, so it should not be so 
> wrong ;-)
> Thanks a lot for your help.
> Best regards
> Eric Pascual