Subject: | |
From: | |
Reply To: | |
Date: | Tue, 24 Jan 2006 17:21:10 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Eric,
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
>
|
|
|