[Tutor] Structure of my simulation / monte-carlo

[Dave Angel]

Dave Angel wrote:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">Kent 
> Johnson wrote:
>> On Sun, Nov 1, 2009 at 10:47 AM, Vincent Davis 
>> <vincent at vincentdavis.net> wrote:
>>  
>>> Kent Johsnon writes
>>> "This class has a lot of responsibilities:
>>> - create applicants
>>> - create institutions
>>> - run a single match
>>> - run multiple matches
>>> - calculate statistics on the result of multiple matches
>>> A principle of object-oriented design is that a class should have a
>>> single responsibility. I would break your class up a bit using
>>> multiple classes, perhaps."
>>> I am trying to do what you recomend, as much as makes sense to me, 
>>> but that
>>> is why I ask the question so I should consider your answer.
>>> This is what I hear you saying, (I don't mean to represent them as
>>> sub-classes but more how they would operate on each other) Should I 
>>> consider
>>> making Institutions) a subclass of (Make Institutions)? I can't 
>>> think of
>>> anything that would make sense to inherit.
>>> class Simulation:
>>>     class Create Institutions:
>>>         class Institutions:
>>>     class create Applicants:
>>>         class Applicants:
>>>     class Match:
>>>     class Multi Match:
>>> I add I am thinking
>>> class Simulation:
>>>     def__init__:(self, results, stats.....repeat..)
>>>     def create_applicants():
>>>         class Applicants
>>>     def creat_institutions():
>>>         class Institutions
>>>     def one_simulation(): # one or more
>>>         create_applicants()
>>>         create_institutions()
>>>         class Match()
>>>         class Results
>>>     def repeat_simulation()
>>>         repeat one_simulations
>>>         class Results
>>> After writing this out I now think you are right, more classes.
>>>     
>>
>> Now you are getting too complicated. You don't need to use inheritance
>> or nested classes, and you can use simple methods (not classes) to
>> create applicants and institutions. You already have Applicant,
>> Institution and Match classes that run a single match. Now make a
>> RepeatMatch class that uses the Match class to run multiple
>> simulations.
>>
>> Kent
>>
>>   
> I mostly agree with Kent, but I apparently disagree about which 
> classes are actually needed.  Think what things will have actual 
> instances that will last long enough to be worth formally defining.  
> So you need Applicant, and Institution, and Simulation.  Notice 
> they're all singular.  I'm assuming one simulation is a single set of 
> test data, with its results.  Then you create as many instances of 
> Simulation as you need for comparison purposes, and perhaps keep a 
> list of them.  It's not clear that list needs any further structure 
> than the built-in list type provides.
>
> You don't need a class for creating an Applicant, that's just a line 
> or two in a loop in the Simulation class.  Similarly for Institution.
>
> And if I understand it correctly, you don't need very many different 
> methods in Simulation either.  You need the __init__ to save enough 
> information to "tag" this particular simulation (call it a label, it's 
> probably just a string).  If __init__ is too complex, you may want to 
> break it into several phases.  But they'll always be called in direct 
> succession, so there may not be any point.  Then you need something 
> that triggers an analysis, and something that queries for particular 
> results.  That last will then be called from plotting or charting 
> routines.
>
> But you probably don't need anything special for a collection of 
> Simulation objects.  A list will probably be fine.
>
> And from what you said earlier, you WILL need function objects, 
> probably as parameters to the Simulation constructor.  So each 
> instance of Simulation will be given several function objects to 
> specify the distribution functions for the parameters to be used when 
> creating Applicants and Institutions.
>
> DaveA
>
Upon rereading, I think I have to disagree with myself.  Not being that 
acquainted with Monte Carlo simulations, I forgot that you would be 
creating many simulations with one set of function objects, then moving 
on to a different set of function objects.  So you do need some form of 
collection class.  At this point, I'm lost without something more 
concrete, so I'll try to bow out in favor of Kent and his ideas.

DaveA