Re: [om-devel] Bringing the branches together, moving forward, etc.

[Kevin R. <kr...@ku...>]

Tim,

The short answer is "Yes".

Kevin

Tim Sutton wrote:

>Hi Kevin + gang
>
>Excellent stuff going on here. Could I just ask that you tag cvs again just 
>prior to merging with something like "openmodeller_gui_02_works"
>
>After you have merged I will then update the current gui to work with head.
>
>Regards
>
>Tim
>
>On Monday 06 December 2004 18:27, Kevin Ruland wrote:
>  
>
>>Hi all,
>>
>>In case you haven't noticed by the barrage of om-cvs emails,  I have
>>been hacking away at branched code.  There are quite a number of
>>features in this code base which should be part of the trunk.  I am
>>aware that Mauro has been working on a branch as well and thought this
>>would be a good time to discuss merging the branches and comming back
>>together.
>>
>>Here's a list of the things which I have done on this branch - and the
>>thing that Ricardo did as well:
>>
>>1)  Partially implemented an alternative sampler which operates with
>>reduced environment data.  Instead of loading the entire environment
>>from raster files, it is only provided with environment data at
>>occurrences/absences.  (Ricardo).
>>
>>2)  Reimplemented serialization/deserialization mechanism.  The
>>serialized state is seperated from the file format.  There is a
>>configuration object which is read from/written to files.  The
>>configuration object can be used to build objects in OpenModeller.  (Kevin)
>>
>>3)  Implemented Model and Algorithm seperataion.  I have build an
>>interface called Model which abstracts the portion of Algorithm which is
>>used for evaluations.  This includes "getValue" and "normalization of
>>environment."  (Kevin)
>>
>>4)  Moved environment normalization (and paramters) from deep in the
>>environment classes into Model.  In my opinion this information
>>rightfully belongs in the Model because it is simply one piece of the
>>mathematical function from environment data vector into probability.
>>The actual normalization is still done in Environment and
>>setNormalization still exists.  I did this simply for time reasons and
>>intend on moving that code up higher (into ScaledModel abstract
>>class).   If you look at the old code, there were about 4 objects which
>>participated in the setNormalization call most of which were simply
>>doing delegation.  Now it is much simpler.  Having the parameters in
>>Model also facilitates the serialization mechanism.
>>
>>5)   Implemented reference-counting smart pointers for all major
>>objects:  Algorithm, Model, Environment, Occurrences, Sampler,
>>Configuration.  Three of these (Algorithm, Model, Configuration) are
>>hand coded, the other three (Environment, Occurrences, Sampler) use a
>>template in refcount.hh.  The three hand coded ones were done first,
>>then when I realized that a template would save time.  I intend on going
>>back and making the first three use the template too.  The current
>>template definition is lacking because it doesn't grok const-ness of the
>>underlying pointer - but since very little of the code was const-correct
>>to begin with, this is little penalty now.   Perhaps some curagous
>>person out there wants to add type traits to it?   I was not very
>>careful changing the other objects to smartly pass these around almost
>>all calls are by value now.  This does incurr some overhead but can be
>>reduced in the future.  Also, the current DList/List class is not very
>>friendly with value types and there is a lot of operator=() /
>>copy-constructor thrashing in the occurrence_file.cpp TU.    The upside
>>- and a big upside it is - there is no longer a worry about who owns
>>which big object.  Also, since most of the access to these objects were
>>through pointers anyway, there is no additional runtime overhead.
>>
>>6)  AlgorithmFactory is now a proper singleton.  It is implemented using
>>the standard singleton pattern which has been around for many years
>>now.   It still doesn't address the problems with threading or
>>refreshing dlls, etc. but it does solve the problem experienced by Tim
>>in the qgis gui.  For example, he now doesn't need to have any
>>OpenModller objets in his code.  He can just query the AlgorithmFactory
>>directly for the metadata, etc.
>>
>>7)  Various memory leaks and unintialized values addressed as indicated
>>by valgrind.
>>
>>That's pretty much the list I remember.  Now on to the future.
>>
>>Mauro, I know you were working in brach-model-manager.  I pulled that
>>brach and tried to discern the changes you were making.  It would
>>probably be better if you described what you had done, and come to
>>common ground rather than me trying to surreptitiously discover it on my
>>own.  I know you were seperating Model from Algorithm as well, and saw
>>that you had pulled out of OpenModeller the algorithm iteration loop.
>>Any other things going on in there?
>>
>>This is where I 'd like to see the code going:
>>
>>1)  Low layer:  The bottom would be the core objets which do what
>>OpenModller project is for.  Provide a pluggable abstraction layer to
>>implement statistical modelling for biological/environmental sciences.
>>The core code of this project is actually much more general what what
>>we're using it for,... but total world domination is not on my adjenda.
>>The objects & abstractions I see here are:  Algorithm (and it's dll
>>implementation guildlines), Model, Environment, Occurrences, Sampler.
>>
>>2)  Serialization mechanism for all these objects:  Configuration.
>>
>>3)  Various controller objects build as needed for different
>>applications.  OpenModeller right now is the principal controller, but
>>it need not be the only controller.
>>
>>4)  Utilize STL where appropriate.  That is where it does not greatly
>>impact performance.  So, string should be used because strings are not
>>core to the algorith.  I would hesitate to put vector<> in Environment
>>or Sampler, but wouldn't hesitate to put vector<string> in
>>AlgorithmFactory or Configuration.
>>
>>5)  Consistant exception mechansim.  I believe we should be using
>>exceptions for exceptional circumstances.  This includes declaring them
>>in the exposed API as well.  Yes, there is overhead to using exceptions,
>>but they greatly simplify problems like reporting problems in the Low
>>layer back to user land code.
>>
>>6)  Occurrences, Sampler, SampledData.  I was trying to work on
>>Occurrences last night and discovered it is very tightly tied to Sampler
>>and other classes as well.  There should be some effort expended here to
>>discover what the true seperation of functionality is.  Since Ricardo
>>had recently changed Sampler to add functionality (and duplicate
>>functionality !), he should perhaps drive this.
>>
>>7)  Removal/Deprecation of dupicated functionality.   Any ideas here?  I
>>have some.
>>
>>8)  Repository restructuring and naming convention.  I'm getting pretty
>>tired of guessing what the header is called....
>>
>>Kevin
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>openModeller-devel mailing list
>>ope...@li...
>>https://lists.sourceforge.net/lists/listinfo/openmodeller-devel
>>    
>>
>
>  
>