[Tutor] Structure of my simulation / monte-carlo
Vincent Davis
vincent at vincentdavis.net
Mon Nov 2 02:53:03 CET 2009
Thanks again for all your help Kent and Dave.
I think you won't here from me for a week or more as I digest your advise
and work on my project.
Thanks
Vincent Davis
720-301-3003
On Sun, Nov 1, 2009 at 6:34 PM, Dave Angel <davea at ieee.org> wrote:
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20091101/5e6fa32e/attachment.htm>
More information about the Tutor
mailing list