#16331: Game Theory: Build capacity to solve matching games in to Sage.
-------------------------------------+-------------------------------------
       Reporter:  vinceknight        |        Owner:
           Type:  enhancement        |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-6.4
      Component:  game theory        |   Resolution:
       Keywords:  Game Theory,       |    Merged in:
  Matching Games,                    |    Reviewers:
        Authors:                     |  Work issues:
Report Upstream:  N/A                |       Commit:
         Branch:                     |  508d8193ea3d99dda90515bced36c8cd8e747224
  public/game_theory/solve_matching_games-16331|     Stopgaps:
   Dependencies:                     |
-------------------------------------+-------------------------------------

Comment (by kcrisman):

 More minor things.
 * Confused here:
 {{{
 a bespoke creation of preferences
 }}}
   Is this a Britishism I'm not aware of?
 * I feel like `revr` shouldn't be the name of just reviewers in this
 example but then not in the init... unless that is to support something
 along the lines of `MatchinGame(suit, revr)`, as the code implies?  But
 then that should be doctested.
 {{{

     def __init__(self, generator, revr=None):
         r"""
         Initialize a matching game and check the inputs.

         TESTS::

             sage: suit = {0: (3, 4), 1: (3, 4)}
             sage: revr = {3: (0, 1), 4: (1, 0)}
             sage: g = MatchingGame([suit, revr])
             sage: TestSuite(g).run()
 }}}
   Indeed, all input methods should be mentioned fairly clearly somewhere
 at the top (maybe even an `INPUT` block?  Though this isn't a function...
 hmm) and you don't use this on in the huge useful top block either.  But
 in either case I am pretty sure that
 {{{
 TypeError("generator must be an integer or a pair of 2 dictionaries")
 }}}
   is wrong or not tested.
 * I'll let you figure out what is wrong with this one.  I guarantee that
 with correct input no one will ever notice it, though!
 {{{
         return 'A matching game with {} suitors and {} reviewers'.format(
                     len(self._reviewers), len(self._suitors))
 }}}
 * Really?
 {{{
     def __eq__(self, other):
         return (isinstance(other, MatchingGame)
                 and set(self._suitors) == set(other._suitors)
                 and set(self._reviewers) == set(other._reviewers))
 }}}
   But... what about the preferences?  Is it still the same game if they
 are different?  (Maybe Travis asked this at some point.)
 * Has not, presumably.
 {{{
 Raise an error if the game has been solved yet.
 }}}
 * In `is_complete` I'd still really like some checks for preference tuples
 that are the "wrong size" somehow.  For instance, someone accidentally
 types in `(1,2,2,3)` instead of `(1,2,3)`.
 * I'm still not quite happy with the `add_suitor` (presumably also
 reviewer) default.   I like that you now have the error check for the name
 being doubled, but I think that the ''automatic'' addition of a suitor
 shouldn't raise this error.  If `name = len(self._suitors) + 1` raises
 that error, couldn't one just keep adding one until it works?  Sorry about
 asking this, but I just know we want to make this very user-friendly since
 most targeted users of this will not be as familiar with Sage or math
 programs...
 * I think you need some examples where someone creates a game, and then
 all of a sudden realizes they need to add (say) a suitor and reviewer, or
 maybe they just do them by hand, but anyway where they need to add
 preferences one at a time.  You don't really have a method for this, just
 `Player.pref` the list of preferences.  That should have several good
 examples.
 * Also, what if someone adds a player to a pre-existing game (well, two!)
 and then has to update '''all''' preferences to make it complete?  Is that
 possible or supported?  If not, how do we indicate this?

 I hope that continuing to ask these questions is okay.  Really it is
 already quite good, but I just want it to be great since it came from GSOC
 and because this is such new stuff.

--
Ticket URL: <http://trac.sagemath.org/ticket/16331#comment:87>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to