search

theref / sage-game-theory

7 stars 3 forks source link

Move maximization from the solvers to game generation #99

Closed ptigwe closed 9 years ago

ptigwe commented 9 years ago

I feel it might be best to move the 'maximization' parameter which all the solvers have into the constructor of the game. In my opinion, the possible options would be as follows

Given matrices 'A' and 'B':

I'm kind of partial to the first two, mainly because we don't have to keep negating the payoff matrices every time we want to solve the game. Also, I've got a function which converts from sage to gambit based on the code within '_solve_LCP', which would benefit other solver functions, and it would be best to have the game in the proper form before converting it to gambit format.

drvinceknight commented 9 years ago

I am unhelpfully undecided on what I feel is best.

I believe that the current setup was motivated by the idea that a game is not defined by the utilisation (max/min) framework.

Out of your four suggestions I think I prefer the second one ('maximization' in the constructor) but feel that the fourth should also be implemented (it does no harm).

With regards to backwards compatibility what is stopping us going with maximization in the construct as well as leaving it also in the solver? Perhaps we could throw in a depreciation warning... Does this [the maximization=False option in solve] need to not be there so as to not mess with other things you are implementing?

Let's see what everyone else thinks.

Pinging @theref.

ptigwe commented 9 years ago

There's nothing stopping us from going with maximization in the constructor. Putting a depreciation warning would work just fine.

drvinceknight commented 9 years ago

That probably sounds like the way to go then (basically you'd be implementing an enhancement)...

dimpase commented 9 years ago

I find the maximization parameter in this context quite misleading. I'd just get rid of it. Imagine that at some point you'd want to solve games for the best NE...

drvinceknight commented 9 years ago

I find the maximization parameter in this context quite misleading. I'd just get rid of it. Imagine that at some point you'd want to solve games for the best NE...

What's misleading?

Solving game for the 'best' NE could just be wrapped around the output could it not (so does not necessarily need to be part of the class)? I think it is worth having something like this though even if only from a teaching point of view so that it's easy enough to decide what type of framework the players are in...

It is meant to be similar to to the interface to MILP:

p = MixedIntegerLinearProgram(maximization=False, solver = "GLPK")

Note that writing that down like that really does imply that @ptigwe's suggestion to move it to generator makes sense... (If only for consistency...)

theref commented 9 years ago

are there any situations where you might want to solve a game both with and without maximisation? (I could only think of within a classroom). If so, it seems excessive to have to rebuild the game with maximisation=True when currently you could just solve it again.

Again, from a teaching point of view, is it useful to be able to show that

NormalFormGame([A, B]).solve()
==
NormalFormGame([-A, -B]).solve(maximization=True)

These are the only reasons I came up with for keeping it as is. I do however think that being able to do 

g = NormmalFormGame([A, B]
-1 * g

would be quite cool. Not sure if it's actually useful or if I'm just being a bit nerdy.

ptigwe commented 9 years ago

are there any situations where you might want to solve a game both with and without maximisation?

None that I can think of.

Again, from a teaching point of view, is it useful to be able to show that

NormalFormGame([A, B]).solve()
==
NormalFormGame([-A, -B]).solve(maximization=True)

I think you meant maximiztion=False. If the construction was different, or if the algorithms available for solving games when players are trying to minimize their payoffs were different, then it would be useful to show that they are equivalent. Otherwise, in the current situation, it's not that interesting to show that game (A, B) == (--A,--B).

However, what might be interesting from a teaching point of view, would be to show that the game (A,B) == (c*A, c*B) for a constant c > 0 and that (A, B) != (c*A, c*B) for a constant c <= 0 and a non-zero bimatrix (A, B).

I'm tending to agree with Dima on removing maximization completely, which means the scaling can be done on the original matrices. Also the idea of having -1 * g would be a nice short-cut, however it might not be what you want if all you want is to negate a single player's payoff matrix.

drvinceknight commented 9 years ago

On 29 May 2015 1:55 pm, "Tobenna P. Igwe" notifications@github.com wrote:

are there any situations where you might want to solve a game both with and without maximisation?

None that I can think of.

Again, from a teaching point of view, is it useful to be able to show that

NormalFormGame([A, B]).solve()

NormalFormGame([-A, -B]).solve(maximization=True)

I think you meant maximiztion=False. If the construction was different, or if the algorithms available for solving games when players are trying to minimize their payoffs were different, then it would be useful to show that they are equivalent. Otherwise, in the current situation, it's not that interesting to show that game (A, B) == (--A,--B).

I agree BUT it's still useful to demonstrate it.

However, what might be interesting from a teaching point of view, would be to show that the game (A,B) == (c_A, c_B) for a constant c > 0 and that (A, B) != (c_A, c_B) for a constant c <= 0 and a non-zero bimatrix (A, B).

I'm tending to agree with Dima on removing maximization completely, which means the scaling can be done on the original matrices. Also the idea of having -1 * g would be a nice short-cut, however it might not be what you want if all you want is to negate a single player's payoff matrix.

I can't say I'm terribly excited about getting rid of it. I used the option in class and it was particularly useful to show that it was equivalent to scaling the matrices.

(replying very briefly as at a wedding)

— Reply to this email directly or view it on GitHub.

dimpase commented 9 years ago

On 29 May 2015 at 14:06, Vince Knight notifications@github.com wrote:

On 29 May 2015 1:55 pm, "Tobenna P. Igwe" notifications@github.com wrote:

are there any situations where you might want to solve a game both with and without maximisation?

None that I can think of.

Again, from a teaching point of view, is it useful to be able to show that

NormalFormGame([A, B]).solve()

NormalFormGame([-A, -B]).solve(maximization=True)

I think you meant maximiztion=False. If the construction was different, or if the algorithms available for solving games when players are trying to minimize their payoffs were different, then it would be useful to show that they are equivalent. Otherwise, in the current situation, it's not that interesting to show that game (A, B) == (--A,--B).

I agree BUT it's still useful to demonstrate it.

However, what might be interesting from a teaching point of view, would be to show that the game (A,B) == (c_A, c_B) for a constant c > 0 and that (A, B) != (c_A, c_B) for a constant c <= 0 and a non-zero bimatrix (A, B).

I'm tending to agree with Dima on removing maximization completely, which means the scaling can be done on the original matrices. Also the idea of having -1 * g would be a nice short-cut, however it might not be what you want if all you want is to negate a single player's payoff matrix.

I can't say I'm terribly excited about getting rid of it. I used the option in class and it was particularly useful to show that it was equivalent to scaling the matrices.

I don't think options only useful for teaching belong to the main Sage library. Feel free to create a customised class...

drvinceknight commented 9 years ago

Really? The main reviewer of the original tickets and I had quite a few conversations of what should be in this class from a teaching point of view... I would suggest that because of SMC it actually makes sense to have a very accessible set of tools.

I think if this option gets removed then it should arguably be removed from MILP no?

On Fri, 29 May 2015 14:11 Dmitrii Pasechnik notifications@github.com wrote:

On 29 May 2015 at 14:06, Vince Knight notifications@github.com wrote:

On 29 May 2015 1:55 pm, "Tobenna P. Igwe" notifications@github.com wrote:

are there any situations where you might want to solve a game both with and without maximisation?

None that I can think of.

Again, from a teaching point of view, is it useful to be able to show that

NormalFormGame([A, B]).solve()

NormalFormGame([-A, -B]).solve(maximization=True)

I think you meant maximiztion=False. If the construction was different, or if the algorithms available for solving games when players are trying to minimize their payoffs were different, then it would be useful to show that they are equivalent. Otherwise, in the current situation, it's not that interesting to show that game (A, B) == (--A,--B).

I agree BUT it's still useful to demonstrate it.

However, what might be interesting from a teaching point of view, would be to show that the game (A,B) == (c_A, c_B) for a constant c > 0 and that (A, B) != (c_A, c_B) for a constant c <= 0 and a non-zero bimatrix (A, B).

I'm tending to agree with Dima on removing maximization completely, which means the scaling can be done on the original matrices. Also the idea of having -1 * g would be a nice short-cut, however it might not be what you want if all you want is to negate a single player's payoff matrix.

I can't say I'm terribly excited about getting rid of it. I used the option in class and it was particularly useful to show that it was equivalent to scaling the matrices.

I don't think options only useful for teaching belong to the main Sage library. Feel free to create a customised class...

— Reply to this email directly or view it on GitHub https://github.com/theref/sage-game-theory/issues/99#issuecomment-106799231 .

drvinceknight commented 9 years ago

I suppose what I'm wondering is what harm does the optional argument do? (it's certainly worth while discussing it and making sure that if something should not be there that it is removed so it's good that we're doing that) :)

On Fri, 29 May 2015 14:17 Vincent Knight vincent.knight@gmail.com wrote:

Really? The main reviewer of the original tickets and I had quite a few conversations of what should be in this class from a teaching point of view... I would suggest that because of SMC it actually makes sense to have a very accessible set of tools.

I think if this option gets removed then it should arguably be removed from MILP no?

On Fri, 29 May 2015 14:11 Dmitrii Pasechnik notifications@github.com wrote:

On 29 May 2015 at 14:06, Vince Knight notifications@github.com wrote:

On 29 May 2015 1:55 pm, "Tobenna P. Igwe" notifications@github.com wrote:

are there any situations where you might want to solve a game both with and without maximisation?

None that I can think of.

Again, from a teaching point of view, is it useful to be able to show that

NormalFormGame([A, B]).solve()

NormalFormGame([-A, -B]).solve(maximization=True)

I think you meant maximiztion=False. If the construction was different, or if the algorithms available for solving games when players are trying to minimize their payoffs were different, then it would be useful to show that they are equivalent. Otherwise, in the current situation, it's not that interesting to show that game (A, B) == (--A,--B).

I agree BUT it's still useful to demonstrate it.

However, what might be interesting from a teaching point of view, would be to show that the game (A,B) == (c_A, c_B) for a constant c > 0 and that (A, B) != (c_A, c_B) for a constant c <= 0 and a non-zero bimatrix (A, B).

I'm tending to agree with Dima on removing maximization completely, which means the scaling can be done on the original matrices. Also the idea of having -1 * g would be a nice short-cut, however it might not be what you want if all you want is to negate a single player's payoff matrix.

I can't say I'm terribly excited about getting rid of it. I used the option in class and it was particularly useful to show that it was equivalent to scaling the matrices.

I don't think options only useful for teaching belong to the main Sage library. Feel free to create a customised class...

— Reply to this email directly or view it on GitHub https://github.com/theref/sage-game-theory/issues/99#issuecomment-106799231 .

dimpase commented 9 years ago

by the way, why .solve(), and not .findNashEq (or something like this?)]

There are several solution concepts for games, as you surely know...

On 29 May 2015 at 14:17, Vince Knight notifications@github.com wrote:

Really? The main reviewer of the original tickets and I had quite a few conversations of what should be in this class from a teaching point of view... I would suggest that because of SMC it actually makes sense to have a very accessible set of tools.

I think if this option gets removed then it should arguably be removed from MILP no?

On Fri, 29 May 2015 14:11 Dmitrii Pasechnik notifications@github.com

wrote:

On 29 May 2015 at 14:06, Vince Knight notifications@github.com wrote:

On 29 May 2015 1:55 pm, "Tobenna P. Igwe" notifications@github.com wrote:

are there any situations where you might want to solve a game both with and without maximisation?

None that I can think of.

Again, from a teaching point of view, is it useful to be able to show that

NormalFormGame([A, B]).solve()

NormalFormGame([-A, -B]).solve(maximization=True)

I think you meant maximiztion=False. If the construction was different, or if the algorithms available for solving games when players are trying to minimize their payoffs were different, then it would be useful to show that they are equivalent. Otherwise, in the current situation, it's not that interesting to show that game (A, B) == (--A,--B).

I agree BUT it's still useful to demonstrate it.

However, what might be interesting from a teaching point of view, would be to show that the game (A,B) == (c_A, c_B) for a constant c > 0 and that (A, B) != (c_A, c_B) for a constant c <= 0 and a non-zero bimatrix (A, B).

I'm tending to agree with Dima on removing maximization completely, which means the scaling can be done on the original matrices. Also the idea of having -1 * g would be a nice short-cut, however it might not be what you want if all you want is to negate a single player's payoff matrix.

I can't say I'm terribly excited about getting rid of it. I used the option in class and it was particularly useful to show that it was equivalent to scaling the matrices.

I don't think options only useful for teaching belong to the main Sage library. Feel free to create a customised class...

— Reply to this email directly or view it on GitHub < https://github.com/theref/sage-game-theory/issues/99#issuecomment-106799231

.

— Reply to this email directly or view it on GitHub https://github.com/theref/sage-game-theory/issues/99#issuecomment-106800095 .

drvinceknight commented 9 years ago

It actually is obtainNash.

On Fri, 29 May 2015 14:43 Dmitrii Pasechnik notifications@github.com wrote:

by the way, why .solve(), and not .findNashEq (or something like this?)]

There are several solution concepts for games, as you surely know...

On 29 May 2015 at 14:17, Vince Knight notifications@github.com wrote:

Really? The main reviewer of the original tickets and I had quite a few conversations of what should be in this class from a teaching point of view... I would suggest that because of SMC it actually makes sense to have a very accessible set of tools.

I think if this option gets removed then it should arguably be removed from MILP no?

On Fri, 29 May 2015 14:11 Dmitrii Pasechnik notifications@github.com

wrote:

On 29 May 2015 at 14:06, Vince Knight notifications@github.com wrote:

On 29 May 2015 1:55 pm, "Tobenna P. Igwe" notifications@github.com wrote:

are there any situations where you might want to solve a game both with and without maximisation?

None that I can think of.

Again, from a teaching point of view, is it useful to be able to show that

NormalFormGame([A, B]).solve()

NormalFormGame([-A, -B]).solve(maximization=True)

I think you meant maximiztion=False. If the construction was different, or if the algorithms available for solving games when players are trying to minimize their payoffs were different, then it would be useful to show that they are equivalent. Otherwise, in the current situation, it's not that interesting to show that game (A, B) == (--A,--B).

I agree BUT it's still useful to demonstrate it.

However, what might be interesting from a teaching point of view, would be to show that the game (A,B) == (c_A, c_B) for a constant c > 0 and that (A, B) != (c_A, c_B) for a constant c <= 0 and a non-zero bimatrix (A, B).

I'm tending to agree with Dima on removing maximization completely, which means the scaling can be done on the original matrices. Also the idea of having -1 * g would be a nice short-cut, however it might not be what you want if all you want is to negate a single player's payoff matrix.

I can't say I'm terribly excited about getting rid of it. I used the option in class and it was particularly useful to show that it was equivalent to scaling the matrices.

I don't think options only useful for teaching belong to the main Sage library. Feel free to create a customised class...

— Reply to this email directly or view it on GitHub <

https://github.com/theref/sage-game-theory/issues/99#issuecomment-106799231

.

— Reply to this email directly or view it on GitHub < https://github.com/theref/sage-game-theory/issues/99#issuecomment-106800095

.

— Reply to this email directly or view it on GitHub https://github.com/theref/sage-game-theory/issues/99#issuecomment-106805297 .

drvinceknight commented 9 years ago

Sorry: obtain_nash.

http://doc.sagemath.org/html/en/reference/game_theory/sage/game_theory/normal_form_game.html

On Fri, 29 May 2015 14:49 Vincent Knight vincent.knight@gmail.com wrote:

It actually is obtainNash.

On Fri, 29 May 2015 14:43 Dmitrii Pasechnik notifications@github.com wrote:

by the way, why .solve(), and not .findNashEq (or something like this?)]

There are several solution concepts for games, as you surely know...

On 29 May 2015 at 14:17, Vince Knight notifications@github.com wrote:

Really? The main reviewer of the original tickets and I had quite a few conversations of what should be in this class from a teaching point of view... I would suggest that because of SMC it actually makes sense to have a very accessible set of tools.

I think if this option gets removed then it should arguably be removed from MILP no?

On Fri, 29 May 2015 14:11 Dmitrii Pasechnik notifications@github.com

wrote:

On 29 May 2015 at 14:06, Vince Knight notifications@github.com wrote:

On 29 May 2015 1:55 pm, "Tobenna P. Igwe" <notifications@github.com

wrote:

are there any situations where you might want to solve a game both with and without maximisation?

None that I can think of.

Again, from a teaching point of view, is it useful to be able to show that

NormalFormGame([A, B]).solve()

NormalFormGame([-A, -B]).solve(maximization=True)

I think you meant maximiztion=False. If the construction was different, or if the algorithms available for solving games when players are trying to minimize their payoffs were different, then it would be useful to show that they are equivalent. Otherwise, in the current situation, it's not that interesting to show that game (A, B) == (--A,--B).

I agree BUT it's still useful to demonstrate it.

However, what might be interesting from a teaching point of view, would be to show that the game (A,B) == (c_A, c_B) for a constant c > 0 and that (A, B) != (c_A, c_B) for a constant c <= 0 and a non-zero bimatrix (A, B).

I'm tending to agree with Dima on removing maximization completely, which means the scaling can be done on the original matrices. Also the idea of having -1 * g would be a nice short-cut, however it might not be what you want if all you want is to negate a single player's payoff matrix.

I can't say I'm terribly excited about getting rid of it. I used the option in class and it was particularly useful to show that it was equivalent to scaling the matrices.

I don't think options only useful for teaching belong to the main Sage library. Feel free to create a customised class...

— Reply to this email directly or view it on GitHub <

https://github.com/theref/sage-game-theory/issues/99#issuecomment-106799231

.

— Reply to this email directly or view it on GitHub < https://github.com/theref/sage-game-theory/issues/99#issuecomment-106800095

.

— Reply to this email directly or view it on GitHub https://github.com/theref/sage-game-theory/issues/99#issuecomment-106805297 .

ptigwe commented 9 years ago

I think if this option gets removed then it should arguably be removed from MILP no?

I don't think it's quite a fair comparison, seeing as the LP remains the same when switch from minimization to maximization, but the same can't be said about games. Also, all the MILP solvers (that I'm aware of) take the optimization direction as a parameter.

In comparison, maximizing payoffs and minimizing costs gives different games, which can be solved by the same algorithm. As a result, I don't feel it's correct to create a different game when trying to solve a game (even though it might be related to the current game). It would be best to create the game separately.

Finally, if we do move maximization to the constructor, then for n-player games or games where payoffs are assigned similar to

 threegame[0, 0, 0][0] = 3

then maximization would have to be made an object variable, so as to be able to maintain it correctly.

drvinceknight commented 9 years ago

On 29 May 2015 3:45 pm, "Tobenna P. Igwe" notifications@github.com wrote:

I think if this option gets removed then it should arguably be removed from MILP no?

I don't think it's quite a fair comparison, seeing as the LP remains the same when switch from minimization to maximization, but the same can't be said about games. Also, all the MILP solvers (that I'm aware of) take the optimization direction as a parameter.

That's a good point. To be clear that point of mine was about removing the parameter altogether and not about moving it to the constructor. I don't see what harm it does to have the parameter but am completely happy to move it if we feel it should be (and perhaps go down the line of the depreciation warning).

In comparison, maximizing payoffs and minimizing costs gives different games, which can be solved by the same algorithm. As a result, I don't feel it's correct to create a different game when trying to solve a game (even though it might be related to the current game). It would be best to create the game separately.

That is an excellent point and one that I feel motivates moving it to the constructor.

Finally, if we do move maximization to the constructor, then for n-player games or games where payoffs are assigned similar to

threegame[0, 0, 0][0] = 3

then maximization would have to be made an object variable, so as to be able to maintain it correctly.

Sorry but I didn't follow this. Could you explain?

— Reply to this email directly or view it on GitHub.

ptigwe commented 9 years ago

If maximization is moved to the constructor, then whenever a payoff entry is set, we would have to multiply by either 1 or -1 depending on the value of maximization which wouldn't be available if it isn't an object variable. On 29 May 2015 15:50, "Vince Knight" notifications@github.com wrote:

On 29 May 2015 3:45 pm, "Tobenna P. Igwe" notifications@github.com wrote:

I think if this option gets removed then it should arguably be removed from MILP no?

I don't think it's quite a fair comparison, seeing as the LP remains the same when switch from minimization to maximization, but the same can't be said about games. Also, all the MILP solvers (that I'm aware of) take the optimization direction as a parameter.

That's a good point. To be clear that point of mine was about removing the parameter altogether and not about moving it to the constructor. I don't see what harm it does to have the parameter but am completely happy to move it if we feel it should be (and perhaps go down the line of the depreciation warning).

In comparison, maximizing payoffs and minimizing costs gives different games, which can be solved by the same algorithm. As a result, I don't feel it's correct to create a different game when trying to solve a game (even though it might be related to the current game). It would be best to create the game separately.

That is an excellent point and one that I feel motivates moving it to the constructor.

Finally, if we do move maximization to the constructor, then for n-player games or games where payoffs are assigned similar to

threegame[0, 0, 0][0] = 3

then maximization would have to be made an object variable, so as to be able to maintain it correctly.

Sorry but I didn't follow this. Could you explain?

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/theref/sage-game-theory/issues/99#issuecomment-106835993 .

drvinceknight commented 9 years ago

On 29 May 2015 3:57 pm, "Tobenna P. Igwe" notifications@github.com wrote:

If maximization is moved to the constructor, then whenever a payoff entry is set, we would have to multiply by either 1 or -1 depending on the value of maximization which wouldn't be available if it isn't an object variable.

Ah yes I'm with you. I wouldn't worry about that though because it's a very particular case...

Your comment about 'different games but same algorithms' would be nice to put in to the docs somewhere...

On 29 May 2015 15:50, "Vince Knight" notifications@github.com wrote:

On 29 May 2015 3:45 pm, "Tobenna P. Igwe" notifications@github.com wrote:

I think if this option gets removed then it should arguably be removed from MILP no?

I don't think it's quite a fair comparison, seeing as the LP remains the same when switch from minimization to maximization, but the same can't be said about games. Also, all the MILP solvers (that I'm aware of) take the optimization direction as a parameter.

That's a good point. To be clear that point of mine was about removing the parameter altogether and not about moving it to the constructor. I don't see what harm it does to have the parameter but am completely happy to move it if we feel it should be (and perhaps go down the line of the depreciation warning).

In comparison, maximizing payoffs and minimizing costs gives different games, which can be solved by the same algorithm. As a result, I don't feel it's correct to create a different game when trying to solve a game (even though it might be related to the current game). It would be best to create the game separately.

That is an excellent point and one that I feel motivates moving it to the constructor.

Finally, if we do move maximization to the constructor, then for n-player games or games where payoffs are assigned similar to

threegame[0, 0, 0][0] = 3

then maximization would have to be made an object variable, so as to be able to maintain it correctly.

Sorry but I didn't follow this. Could you explain?

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub < https://github.com/theref/sage-game-theory/issues/99#issuecomment-106835993> .

— Reply to this email directly or view it on GitHub.

drvinceknight commented 9 years ago

Actually no, ignore what I said about not worrying about it. Your idea is the way to go I think.

On Fri, 29 May 2015 16:01 Vincent Knight vincent.knight@gmail.com wrote:

On 29 May 2015 3:57 pm, "Tobenna P. Igwe" notifications@github.com wrote:

If maximization is moved to the constructor, then whenever a payoff entry is set, we would have to multiply by either 1 or -1 depending on the value of maximization which wouldn't be available if it isn't an object variable.

Ah yes I'm with you. I wouldn't worry about that though because it's a very particular case...

Your comment about 'different games but same algorithms' would be nice to put in to the docs somewhere...

On 29 May 2015 15:50, "Vince Knight" notifications@github.com wrote:

On 29 May 2015 3:45 pm, "Tobenna P. Igwe" notifications@github.com wrote:

I think if this option gets removed then it should arguably be removed from MILP no?

I don't think it's quite a fair comparison, seeing as the LP remains the same when switch from minimization to maximization, but the same can't be said about games. Also, all the MILP solvers (that I'm aware of) take the optimization direction as a parameter.

That's a good point. To be clear that point of mine was about removing the parameter altogether and not about moving it to the constructor. I don't see what harm it does to have the parameter but am completely happy to move it if we feel it should be (and perhaps go down the line of the depreciation warning).

In comparison, maximizing payoffs and minimizing costs gives different games, which can be solved by the same algorithm. As a result, I don't feel it's correct to create a different game when trying to solve a game (even though it might be related to the current game). It would be best to create the game separately.

That is an excellent point and one that I feel motivates moving it to the constructor.

Finally, if we do move maximization to the constructor, then for n-player games or games where payoffs are assigned similar to

threegame[0, 0, 0][0] = 3

then maximization would have to be made an object variable, so as to be able to maintain it correctly.

Sorry but I didn't follow this. Could you explain?

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub < https://github.com/theref/sage-game-theory/issues/99#issuecomment-106835993

.

— Reply to this email directly or view it on GitHub.

drvinceknight commented 9 years ago

I realise my previous reply formatted horribly on github (might look ok on email). Was basically saying that you made great points and probably worth moving to constructor with depreciation as you suggest.

On 29 May 2015 4:06 pm, "Vincent Knight" vincent.knight@gmail.com wrote:

Actually no, ignore what I said about not worrying about it. Your idea is the way to go I think.

On Fri, 29 May 2015 16:01 Vincent Knight vincent.knight@gmail.com wrote:

On 29 May 2015 3:57 pm, "Tobenna P. Igwe" notifications@github.com wrote:

If maximization is moved to the constructor, then whenever a payoff entry is set, we would have to multiply by either 1 or -1 depending on the value of maximization which wouldn't be available if it isn't an object variable.

Ah yes I'm with you. I wouldn't worry about that though because it's a very particular case...

Your comment about 'different games but same algorithms' would be nice to put in to the docs somewhere...

On 29 May 2015 15:50, "Vince Knight" notifications@github.com wrote:

On 29 May 2015 3:45 pm, "Tobenna P. Igwe" notifications@github.com wrote:

I think if this option gets removed then it should arguably be removed from MILP no?

I don't think it's quite a fair comparison, seeing as the LP remains the same when switch from minimization to maximization, but the same can't be said about games. Also, all the MILP solvers (that I'm aware of) take the optimization direction as a parameter.

That's a good point. To be clear that point of mine was about removing the parameter altogether and not about moving it to the constructor. I don't see what harm it does to have the parameter but am completely happy to move it if we feel it should be (and perhaps go down the line of the depreciation warning).

In comparison, maximizing payoffs and minimizing costs gives different games, which can be solved by the same algorithm. As a result, I don't feel it's correct to create a different game when trying to solve a game (even though it might be related to the current game). It would be best to create the game separately.

That is an excellent point and one that I feel motivates moving it to the constructor.

Finally, if we do move maximization to the constructor, then for n-player games or games where payoffs are assigned similar to

threegame[0, 0, 0][0] = 3

then maximization would have to be made an object variable, so as to be able to maintain it correctly.

Sorry but I didn't follow this. Could you explain?

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub < https://github.com/theref/sage-game-theory/issues/99#issuecomment-106835993> .

— Reply to this email directly or view it on GitHub.