#18536: Solvers for constant sum games
-------------------------------------+-------------------------------------
Reporter: ptigwe | Owner:
Type: enhancement | Status: needs_work
Priority: minor | Milestone: sage-6.8
Component: game theory | Resolution:
Keywords: Game Theory, | Merged in:
Gambit, Zero-sum game Constant | Reviewers: Karl-Dieter Crisman
Sum Game, Normal Form Games | Work issues:
Authors: Tobenna P. Igwe | Commit:
Report Upstream: N/A | 60efdc7f823c8aa64ac176addcd376f1f571b09d
Branch: | Stopgaps:
u/ptigwe/gt_extension |
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by ptigwe):
> > I included it again just in case if the `_solve_gambit_LP` function
was called externally without going through `_solve_LP`. If there is no
need to retest just for this reason, then I'm happy to take it out.
> Well, usually such underscore methods aren't "publicly" available.
Vince, what do you think?
Actually, gambit performs it's own check as well, which makes three checks
in total. So I've removed the one within `_solve_gambit_LP`, and added a
doctest for the gambit error.
> > > * `return c.numpy().max() == c.numpy().min()` - is there no way to
do this without using/importing `numpy`? It would be nice to not have to
use it - or is it slower to use Sage proper?
> > Currently, this compares all entries of the matrix and makes sure it
is within `sys.float_info.epsilon` of the first element.
> >
||[http://git.sagemath.org/sage.git/commit/?id=d9571793d208ed772fb8e7a7a335f9934dda1fe8
d957179]||{{{Update check for constant sum 'is_constant_sum'}}}||
> But which one is in principle faster or better? I don't mind using
numpy as long as importing it doesn't cause problems in speed, if it's
better (which perhaps it is).
The current implementation is faster than the numpy implementation. I ran
some bench marks using `timeit` and got `177 µs per loop` for the current
implementation vs `992 ms per loop` for the numpy implementation using a
matrix of size `1000x1000`.
> > Currently, we are considering moving the `maximization` option into
the constructor of the class.
> Fine, but this is currently breaking functionality. So either you have
to do that here, or make that change a prereq to this ticket, or something
else. My recommendation is to just leave it here for now and then deal
with the class constructor bit in a separate ticket (to make things as
orthogonal as possible).
Integrated the `maximization` parameter into `_as_gambit_game`.
--
Ticket URL: <http://trac.sagemath.org/ticket/18536#comment:10>
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.
