Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-02 Thread spir
Le Sun, 01 Nov 2009 20:34:56 -0500,
Dave Angel da...@ieee.org s'exprima ainsi:

 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.

A note on function objects (because you --Vincent-- seem to regard this 
notion as impressive, but maybe I'm wrong).
In python, function objects are functions, no more; all functions (and methods) 
are objects. Simply, the fact that they are objects, indeed, is revealed in the 
cases where you bind them to a name like any other object.

to an ordinary variable:

if random_choice == GAUSS:
randomFunc = gaussRandom

or to a func parameter:

def produceDistribution(self, randomFunc, more_param):
...
random_results = randomFunc(more_param)
self.distrib = Distribution(results)# if you have type for distrib

This is not so often needed, but your case in the good one.

The feature is present in most high-level languages. But this has not been true 
for a long time, especially for mainstream languages of the imperative field 
(while it was more common, even required, for functional languages). So, this 
feature has kept a kind of special prestige and functions are first-class 
objects often comes early in a list of language features. But there is nothing 
exceptional in this for a language like python that basically treats data as 
objects, id est that accesses data through references.

Denis
--
la vita e estrany


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-01 Thread Dave Angel

Vincent Davis wrote:

I ask this question in part because of a fee remarks from another question I
ask class attribute to initiate more classes

Basically I am simulation the process of applicants to schools and trying to
ask/answer some questions like what conditions do you need to have an
optimal solution Oh and to learn python. I basically had it working as a
script rather than using a class structure but it was very inflexible and I
still needed to learn about classes.

What I have these classes
class Applicant: has lots of attributes (self.gpa = random.gauss(50, 10)
about the Applicant and def() defining how/why an applicant applies to an
institution,

class Institution: Lots of attributes (self.quality = random.gauss(50,
10)) about the Institution and def() defining how the institution considers
the applicant.

class Match: this defines the interaction of the population of Applicants
and Institutions, i.e. the rules of the game and returns the outcome i.e.
which Applicants went to which Institutions.

As of now I have been running 1 Match at a time. Which is to say generate
8000 instances of Applicant and 300 instances of Institution and then run
the match Match(app_list, inst_list) and I do this with a short script.

So now I need to implement my monte-carlo. By that I mean that i want to set
some of the initial condition such as GPA, and Quality and basically re-run
the what I descried above, (generate applicant, institutions, match them)
 Then save the results.

So my plan way to make a new class. This class would define the Applicant
characteristics self.gpa = random.gauss(mean, SD) and the
institutions self.quality = random.gauss(mean, sd)

so it would look something like this


class RepeatMatch:
def __int__(self, app_mean, app_sd, inst_mean, inst_sd, match_ repeat)
self.app_mean = app_mean
……..
self.match_repeat = match_repeat

   def makeApplicants():

   def makeInstitutions():

   def runMatches(self)
   # runs the match match_repeat number of times, saves results

# then I calculate some characteristics of the results

def ratio_dist():
 # returns the Mean and sd of GPA/Quality
END OF CODE

Does it make sense to do it this way? Is there a better/alternative way of
thinking about this. In the end I want to compare the results of repeated
simulations RepeatMatch(50,2….) Compared to RepeatMatch(50,15….)
This is way I had ask the earlier question class attribute to initiate more
classes

Thanks
Vincent Davis

  
I worried that you might find my responses too complex, but nobody else 
has responded, and it's been almost a day.


I don't see anything wrong with your approach.  Since you're going to do 
multiple sets of data, it makes sense for an instance of a class 
(RepeatMatch) to hold the data for one such run.  In your original 
sample, it didn't make sense to me, but of course I didn't know where 
you were heading.  So I would add in instance attributes such as  
self.applicants=[]  to your __init__() method of RepeatMatch.  (I 
suspect you're planning to do exactly that)


I would caution you that each instance of RepeatMatch will then hold 
lots of the other members, so keeping them around could be expensive. So 
when run_matches() finishes its analysis, it might want to delete its 
lists of raw data (eg. self.applicants).  But other choices exist, and 
you can decide that when you see how the whole thing fits together.  
Perhaps you'll only have one such instance at a time.  But if you're 
going to do multiple things with the results, you may want this object 
to hang onto the results, but throw away the raw data when all the 
necessary results have been calculated.


Are you sure that the only distribution you're going to use is 
random.gauss() ?  If so, then you only need to pass mean and stddev to 
the RepeatMatch constructor, as you're doing.  But if you might need to 
compare that distribution with a different one, then you might want to 
use a function object, as I tried to describe earlier.



HTH
DaveA
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-01 Thread Kent Johnson
On Sat, Oct 31, 2009 at 12:54 PM, Vincent Davis
vinc...@vincentdavis.net wrote:

 So my plan way to make a new class. This class would define the Applicant
 characteristics self.gpa = random.gauss(mean, SD) and the
 institutions self.quality = random.gauss(mean, sd)
 so it would look something like this

 class RepeatMatch:
     def __int__(self, app_mean, app_sd, inst_mean, inst_sd, match_ repeat)
         self.app_mean = app_mean
         ……..
         self.match_repeat = match_repeat
    def makeApplicants():
    def makeInstitutions():
    def runMatches(self)
    # runs the match match_repeat number of times, saves results
 # then I calculate some characteristics of the results
     def ratio_dist():
          # returns the Mean and sd of GPA/Quality
 END OF CODE
 Does it make sense to do it this way? Is there a better/alternative way of
 thinking about this. In the end I want to compare the results of repeated
 simulations RepeatMatch(50,2….) Compared to RepeatMatch(50,15….)
 This is way I had ask the earlier question class attribute to initiate more
 classes

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
MatchParameters - holds app_mean, etc
Match - create applicants and institutions and run a single match,
yielding a MatchResult
MatchResult - the result of running a single match
RepeatMatch - run multiple matches and accumulate results, yielding a
RepeatResults
RepeatResults - the result of running multiple matches - knows how to
compute stats on itself

You may think of better names, or a different way to organize it, but
the idea is, don't shove everything into one class. Some of these may
be just built-in data structures or very simple classes, such as
MatchParameters which might be a dict or a collections.namedtuple.

Kent
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-01 Thread Vincent Davis
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. Which means
I really need to play with function objects to understand how they are
passed down the layers

Simulation(GPA = random.gauss(50, 10), repeat = 100.)
MakeApplicants(GPA)
Applicants(GPA)  # I need to make sure the GPA is calculated at each
applicant not back at Simulation.

DaveA
ask if it will always be random.gauss? No, I would like it to be anything
from a constant to a much more complex function)

DaveA
I would caution you that each instance of RepeatMatch will then hold lots
of the other members, so keeping them around could be expensive

This means they stay in memory? Is there a way to know how much room a
instance takes up, in memory or hard drive?
I could serialize them a save them to a sqlite when done with a simulation
correct? How is a questions for later.

worried that you might find my responses too complex
I am kinda working in a vacuum, with respect to python programing. Complex
and difficult are ok, The challenge is not knowing what I don't know. I need
to practice with function objects and run a few experiments still to make
sureI understand them.

DaveA and Kent Thanks for all your help, Vincent
To add a little more to what I am doing I am using CherryPy to host this
simulation. So the GPA function and other simulation variables can be
entered in a html form and passed to the Simulation class. Then I am
calculating results as well as using matplotlib to make some plots, these
results and plots then get show. I think I have most of the CherryPy stuff
figured out once I have the Simulations class setup to do the whole thing.
The only part with CherryPy I am still working on is displaying progress on
the browser as the simulations runs, it can take several minutes.

Thanks
Vincent Davis
720-301-3003


On Sun, Nov 1, 2009 at 6:02 AM, Dave Angel da...@ieee.org wrote:

 Vincent Davis wrote:

 I ask this question in part because of a fee remarks from another question
 I
 ask class attribute to initiate more classes

 Basically I am simulation the process of applicants to schools and trying
 to
 ask/answer some questions like what conditions do you need to have an
 optimal solution Oh and to learn python. I basically had it working as a
 script rather than using a class structure but it was very inflexible and
 I
 still needed to learn about classes.

 What I have these classes
 class Applicant: has lots of attributes (self.gpa = random.gauss(50, 10)
 about the Applicant and def() defining how/why an applicant applies to an
 institution,

 class Institution: Lots of attributes (self.quality = random.gauss(50,
 10)) about the Institution and def() defining how the institution
 considers
 the applicant.

 class Match: this defines the interaction of the population of Applicants
 and Institutions, i.e. the rules of the game and returns the outcome i.e.
 which Applicants went to which Institutions.

 As of now I have been running 1 Match at a time. Which is to say generate
 8000 instances of Applicant and 300 instances of Institution and then run
 the match Match(app_list, inst_list) and I do this with a short script.

 So now I need to implement my monte-carlo. By that I mean that i want to
 set
 some of the initial condition such as GPA, and Quality and basically
 re-run
 the what I descried above, (generate applicant, institutions, match them)
  Then save the results.

 So my plan way to make a new class. This class would define the Applicant
 characteristics self.gpa = random.gauss(mean, SD) and the
 institutions self.quality = random.gauss(mean, sd)

 so it would look 

Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-01 Thread Kent Johnson
On Sun, Nov 1, 2009 at 10:47 AM, Vincent Davis vinc...@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
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-01 Thread Vincent Davis
Just to be clear,or try, given a set of applicants and institutions the
Match will always have the same result. So when I am repeating the Match
this only makes sense to do is I am also making new applicants and
institutions. So I am sampling Match results drawn from a process that is
initiated with a distributions set at the applicant and institution level.

Thanks
Vincent Davis


On Sun, Nov 1, 2009 at 9:58 AM, Kent Johnson ken...@tds.net wrote:

 On Sun, Nov 1, 2009 at 10:47 AM, Vincent Davis vinc...@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

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-01 Thread Kent Johnson
On Sun, Nov 1, 2009 at 11:15 AM, Vincent Davis vinc...@vincentdavis.net wrote:
 Just to be clear,or try, given a set of applicants and institutions the
 Match will always have the same result.

Yes. You have to create a new Match, with new Applicants and
Institutions, for each run of the simulation.

 So when I am repeating the Match
 this only makes sense to do is I am also making new applicants and
 institutions. So I am sampling Match results drawn from a process that is
 initiated with a distributions set at the applicant and institution level.

I don't know what you mean by this. A Match can be created with rules
for its distributions. The Match then creates Applicants and
Institutions for its run, does the simulation and returns the results.
A Simulation also has the distribution rules, so it can create Matches
using those rules.

Kent
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-01 Thread Dave Angel

Kent Johnson wrote:

On Sun, Nov 1, 2009 at 10:47 AM, Vincent Davis vinc...@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


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-01 Thread Vincent Davis
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 da...@ieee.org wrote:

 Kent Johnson wrote:

 On Sun, Nov 1, 2009 at 10:47 AM, Vincent Davis vinc...@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



___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-01 Thread Kent Johnson
On Sun, Nov 1, 2009 at 8:34 PM, Dave Angel da...@ieee.org wrote:
 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.

That's pretty much what I have been suggesting. I think you may be
disagreeing with Vincent's interpretation of my suggestion :-) It
might be worth having a results class for the simulation to hold the
code that computes statistics on the results. I think it's probably
worth having a class to run the multiple simulations but that may just
be a function.

 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.

Right.

 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.

Kent.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] Structure of my simulation / monte-carlo

2009-11-01 Thread Dave Angel

Dave Angel wrote:
div class=moz-text-flowed style=font-family: -moz-fixedKent 
Johnson wrote:
On Sun, Nov 1, 2009 at 10:47 AM, Vincent Davis 
vinc...@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

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor