6bdad4c1-1e26-4f2f-a442-a01a2292c181
commented
10 years ago comment:1
(being curious)
Closed drvinceknight closed 10 years ago
6bdad4c1-1e26-4f2f-a442-a01a2292c181
commented
10 years ago (being curious)
kcrisman
commented
10 years ago Changed author from Vince Knight to none
kcrisman
commented
10 years ago Putting to no listed component because truly non fits. Also, author is really for actual author of any changes (which may well be vinceknight! but isn't yet).
d3dfe940-4ef4-4242-81e0-6916cce90212
commented
10 years ago kcrisman
commented
10 years ago Hi, nice to see you starting work already!
I would advise you, though, to start your work locally, rather than do a lot of commits to a branch on Trac, until you have a reasonably well-formed setup. I say this because I know you will be working on it for a while this summer, so it isn't in danger of rotting away! In particular, having good docstrings etc.
I do like that you want to get stuff out early and often. But maybe it would be good to have something you share with Vince (or others interested) for now, so that you can hash out what all needs to be in here, how strings should look, class and module strings, etc. I guess what I'm saying is that it could be very confusing for a reviewer to try to review many different starts and stops and reworkings etc. Of course if this is in close to final form then my apologies.
On an unrelated note, I'm wondering whether there happens to be any faster algorithms for calculating things - there is probably a literature of computational complexity and game theory, like there is in voting. Some of these combinatorial things (e.g. for coalitions) get really nasty really quickly.
New commits:
83a6b0e | creates game_thoery folder and computes shapley value |
drvinceknight
commented
10 years ago Replying to @kcrisman:
Hi, nice to see you starting work already!
I would advise you, though, to start your work locally, rather than do a lot of commits to a branch on Trac, until you have a reasonably well-formed setup. I say this because I know you will be working on it for a while this summer, so it isn't in danger of rotting away! In particular, having good docstrings etc.
That's very helpful, we were wondering what was the best practice and from the documentation thought that using trac was the way to go. We'll move away from trac for now :) This ticket should be ready to review pretty soon.
I do like that you want to get stuff out early and often. But maybe it would be good to have something you share with Vince (or others interested) for now, so that you can hash out what all needs to be in here, how strings should look, class and module strings, etc. I guess what I'm saying is that it could be very confusing for a reviewer to try to review many different starts and stops and reworkings etc. Of course if this is in close to final form then my apologies.
Absolutely no apologies needed :) We weren't sure what was best practice :) We'll push to trac when it's ready to review.
On an unrelated note, I'm wondering whether there happens to be any faster algorithms for calculating things - there is probably a literature of computational complexity and game theory, like there is in voting. Some of these combinatorial things (e.g. for coalitions) get really nasty really quickly.
To the best of my knowledge there isn't. There are various approximation algorithms that exist that could be coded in to here in the future perhaps?
Thanks again for your comments: they're really helpful.
New commits:
83a6b0ecreates game_thoery folder and computes shapley value
Cool
d3dfe940-4ef4-4242-81e0-6916cce90212
commented
10 years ago I've just set up a Github repository at https://github.com/theref/sage-game-theory This is where we will do all of the development work from now on, any comments on that repository would be greatly appreciated. Especially regarding documentation and testing as this is where I feel the least confident. Thanks for your help!
kcrisman
commented
10 years ago I've just set up a Github repository at https://github.com/theref/sage-game-theory This is where we will do all of the development work from now on, any comments on that repository would be greatly appreciated. Especially regarding documentation and testing as this is where I feel the least confident.
That's a great idea. This is very similar to what the sage matroids folks did when stated to develop it.
Thanks for your help!
Hey, I'm looking forward to using this stuff, so I'm the one who will be thanking!
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago 7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
1d3f909 | Null player is broken |
cc636b4 | Completely re wrote the nullplayer method: passed all tests |
cbedc9d | Fixed shapley_value: test wasnt correct |
2d073ce | Removed instance of keys() being used when not needed |
98f04ea | Init tests now pass - used the sage powerset function |
748c46f | tidies up nullplayer fucntion |
0f3c842 | tidies up symmetry |
0ef8feb | adds extra test to null player |
b5989a4 | adds test for characteristic function being unordered |
0fc261b | removes useless test |
d3dfe940-4ef4-4242-81e0-6916cce90212
commented
10 years ago This is now ready for reviewing. All our discussions can be viewed at https://github.com/theref/sage-game-theory/issues?state=open if there is any confusion with some of our decisions. To anyone kind enough to review the code, in addition to a comment on trac, could they please create a corresponding issue on Github, it would be greatly appreciated.
We will now start working on ticket #16333.
kcrisman
commented
10 years ago I'll try to look at this later today for some initial comments.
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago Branch pushed to git repo; I updated commit sha1. New commits:
f9bd436 | sorts the keys in char_fun |
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago kcrisman
commented
10 years ago I'll try to look at this later today for some initial comments.
Okay, here are my initial thoughts. They're not in priority order, just the order I thought about them in.
I really dislike the necessity of using tuples and dictionaries to initialize the games. I understand why! But for instance, it requires the very annoying ('A',) syntax for tuples with one element. You should at least allow any iterable as a key - but unfortunately the keys need to be hashable. So as a corollary, dictionaries are not awesome for the games.
Of course, then the question is "okay, mister smarty-pants, do you have a better idea?" And the truth is I don't, yet. This implementation is more flexible than Shap.py, it's true. As a starting point, it might be useful to demonstrate using a short program to generate the dictionaries needed from an input of, say, five players and some rule on payoffs.
get_predecessors seems pointless as a separate function.marginal_contributions).drvinceknight
commented
10 years ago Replying to @kcrisman:
I'll try to look at this later today for some initial comments.
Okay, here are my initial thoughts. They're not in priority order, just the order I thought about them in.
Thanks a lot for getting back so quick: this is all super helpful.
- First, there are lots of little formatting things in docstrings. I won't bother about them now, might even just try to comment on github eventually. But they are there. Please study other modules' docstrings carefully - especially with regard to length of lines and where to put double colons and blank lines.
Will do. We were keen to get this up here fast so as to see where we were with bigger potential problems (that you've picked up below). Is that generally an ok practice or is it felt to be bad etiquette to push to trac things that could be better?
I really dislike the necessity of using tuples and dictionaries to initialize the games. I understand why! But for instance, it requires the very annoying
('A',)syntax for tuples with one element. You should at least allow any iterable as a key - but unfortunately the keys need to be hashable. So as a corollary, dictionaries are not awesome for the games.Of course, then the question is "okay, mister smarty-pants, do you have a better idea?" And the truth is I don't, yet. This implementation is more flexible than Shap.py, it's true. As a starting point, it might be useful to demonstrate using a short program to generate the dictionaries needed from an input of, say, five players and some rule on payoffs.
I had thought about this for a while and agree that (A,) isn't the best. Just on this minor point, we thought about having a clean up in the init method that would handle A, (A,) as well as (A) but require (A,B) for two tuples etc... Is this a done thing?
Ultimately, re dictionaries as you say: I don't see a better way of doing it. We need to map all the coalitions to values... Would be great if we could think of a nicer way of doing this...
- Might as well allow easy implementation of a subclass of Simple Games. (In this case, one could imagine an initializer that uses either a list of winning coalitions, or this initialization.)
- Banzhaf, other values?
- What if one assumed the game to be additive? Maybe then it could be inputted in a more straightforward way?
I'm not entirely sure I follow... This sounds very particular and restrictive... I agree that dictionaries are a pain but they do fit the defining of a characteristic game... Not throwing the idea out: just writing down my initial thoughts...
- There should be mathematical descriptions of each concept in its documentation. For instance, the Bessel function documentation is practically an intro to Bessel functions.
We wondered about this. We will include it!
- Should Shapley be the payoff vector? Indeed, isn't the point that there could be many possible payoff vectors? (The core, etc.)
That's why we added the ability to check certain properties (suparrditivity, nullplayer) for ANY vector so that any vector could be set as an attribute and in effect compared to the Shapley value. Should this be made more explicit? Perhaps setting the Shapley_value to be the payoff_vector by default when running the shapley method isn't the way to go...
- Should one use Python permutations or Sage ones?
I have no idea... Is there a best practice with this sort of thing?
get_predecessorsseems pointless as a separate function.- You could use list comprehensions some places (e.g.
marginal_contributions).- That same function is really, really hard to figure out. There is no context whatsoever. I finally figured out what you meant, but it's pretty hermetic. That said, I'm not sure how to put that information about the permutations in without a very long thing. Maybe a better solution would be to put marginal contributions of a player specific to a coalition. That way you both avoid dealing with permutations, which isn't very natural here (as opposed to coalitions, which is fundamental) as well as make the user ask for what they want instead of providing them an information dump, which could be very bad with more than three players :)
I agree that this can be tidied. It will be.
- Oh, I see, you use it in the Shapley value. I probably should have guessed... but in that case, again, I would make that a 'hidden' (underscored) function. You can still provide the marginal contributions per coalition, of course! But I think the thing for all of them should not show up upon tab-completion because you really only use it for the Shapley value.
Didn't realise that this could be done! Will do :) (Still think it can be tidied)
Finally, I want to affirm that this looks fun and useful so far! It's just hard work thinking of what it should look like, because you want to think about design and not just efficiency for your own research purposes. I had some classes of voting stuff that looked similar - but they are in no shape to be submitted to Sage, they just do what I want them to. This is a little more ambitious, so we need more input. Do you know some cooperative game theory types who might be able to take a look at the organization of this? That would be really helpful; unfortunately, the people I know in simple games probably wouldn't have the time to look at in-progress stuff, though I think they would be very supportive of having it in Sage.
I'm afraid that I don't actually. Cooperative game theory is a small part of a course I teach and not actually within my research fields (ticket 16333 is the big cookie!). My initial idea was that this was actually simple enough (calculation of shapley value) to be a nice first step so that we could figure out how to get the docs right etc... (which we will :)). What is the general procedure for finding reviewers? I'm guessing the main reason this sort of stuff isn't in Sage yet is probably because there aren't that many game theorists using Sage (which lends itself to a Chicken and Egg situation I imagine).
I will see if I can email a few people who might be able to take a look (not people that I know) but I expect they won't be too familiar with Sage... We could give them a demo I suppose and see what they thought...
The big issue re 'how we want it to look' is dictionaries as inputs. I don't see a way around that... (But hope someone else will...). I'll be thinking...
Thanks again for your comments/guidance/tips/time: it's super helpful.
kcrisman
commented
10 years ago Thanks a lot for getting back so quick: this is all super helpful.
Well, I'm pretty motivated because this is far more directly related to my research than most things in Sage.
- First, there are lots of little formatting things in docstrings. I won't bother about them now, might even just try to comment on github eventually. But they are there. Please study other modules' docstrings carefully - especially with regard to length of lines and where to put double colons and blank lines.
Will do. We were keen to get this up here fast so as to see where we were with bigger potential problems (that you've picked up below). Is that generally an ok practice or is it felt to be bad etiquette to push to trac things that could be better?
To be honest, when we just had the patches system it wasn't such a big deal - people could ignore the patches if they were "rough" because someone else could always pick it up again later. I haven't gotten a good sense with the branch system yet. That said, rough work is better than no work; it was the GSOC context where I though maybe it would be worth doing separately first, because there is a clear time frame and no worries about abandoned code.
- I really dislike the necessity of using tuples and dictionaries to initialize the games. I understand why! But for instance, it requires the very annoying
('A',)syntax for tuples with one element. You should at least allow any iterable as a key - but unfortunately the keys need to be hashable. So as a corollary, dictionaries are not awesome for the games.I had thought about this for a while and agree that
(A,)isn't the best. Just on this minor point, we thought about having a clean up in the init method that would handleA,(A,)as well as(A)but require(A,B)for two tuples etc... Is this a done thing?
I don't see why not, but you would have to be careful, because the dictionary requires hashable keys. So in that case
sage: {'A':1}
{'A': 1}
sage: a = 5
sage: {a:1}
{5: 1}
sage: {2:1}
{2: 1}
sage: {(1,2):1}
{(1, 2): 1}
sage: {[1,2]:1}
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-6-e1906c12ada7> in <module>()
----> 1 {[Integer(1),Integer(2)]:Integer(1)}
TypeError: unhashable type: 'list'so I guess that you could accept a lot of different dictionaries. But then one would want to check whether the singletons really were connected to the larger tuples.
- What if one assumed the game to be additive? Maybe then it could be inputted in a more straightforward way?
I'm not entirely sure I follow...
It may not have been well thought-out by me, either; I meant if (say) (A,B) gave 12 and A gave 7 then it could be computed that B gave 5, but maybe that's not done often. Not necessary, anyway.
- Should Shapley be the payoff vector? Indeed, isn't the point that there could be many possible payoff vectors? (The core, etc.)
That's why we added the ability to check certain properties (suparrditivity, nullplayer) for ANY vector so that any vector could be set as an attribute and in effect compared to the Shapley value. Should this be made more explicit?
No, that was clear.
Perhaps setting the Shapley_value to be the payoff_vector by default when running the shapley method isn't the way to go...
That's what I'm wondering.
- Should one use Python permutations or Sage ones?
I have no idea... Is there a best practice with this sort of thing?
Speed is something that matters, so you might want to check that out. Now that I see what it's for, having Sage inheritance etc. isn't as necessary since you aren't using it for other things.
I'm afraid that I don't actually. Cooperative game theory is a small part of a course I teach and not actually within my research fields (ticket 16333 is the big cookie!). My initial idea was that this was actually simple enough (calculation of shapley value) to be a nice first step so that we could figure out how to get the docs right etc... (which we will :)).
You're right, a toy(ish) implementation of this is a good thing to do as a warm-up. But see Arxiv for a sampler of what people really do...
What is the general procedure for finding reviewers? I'm guessing the main reason this sort of stuff isn't in Sage yet is probably because there aren't that many game theorists using Sage (which lends itself to a Chicken and Egg situation I imagine).
Well, basically you just ask people. I can definitely help. But I would like real experts to weigh in too. Now, it just so happens that there is someone at Oxford who has written a book on the subject and is personally very well known to a certain Sage developer. I wonder if she might be willing to take a look.
By the way, you'll notice that LPs come up in this. So having a robust version of this will be good.
The big issue re 'how we want it to look' is dictionaries as inputs. I don't see a way around that... (But hope someone else will...). I'll be thinking...
So what I'm thinking is that we find a way to make it clear this is a "toy implementation" that would be general enough for someone actually in the field to expand upon.
Here is yet another implementation - see the bottom, and then this link which is - yes! - BSD licensed!!! I think it would definitely be worth contacting these folks to see if we can use/adapt/at least use as information for how to approach this cooperative material.
Thanks again for your comments/guidance/tips/time: it's super helpful.
Thank YOU for actually getting people working on this!
Okay, but least I get too ambitious for coding I'm not doing, let me reiterate that a basic implementation, with as much potential for further development as possible, is what we want here. So for now, exposing as little API as possible is good, so we wouldn't have to deprecate functionality later on.
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago 7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
86d5ad9 | Added simple 8 player game |
2476b7c | Had failed a test, now it doesnt. Turning my machine off for 24 hours+ |
7648215 | Made get_predecessors a hidden function |
bb61296 | Used list comprehensions in marginal contributions |
cdc792c | Made marginal_of_pi hidden |
4c64de6 | Tidied some doc issues with regards to max cols |
8b91f7c | tidies up docs |
ed82c73 | minor changes to docs |
e94888b | makes large changes to get docs to build |
9fccb6f | docs build, but latex not displaying properly |
d3dfe940-4ef4-4242-81e0-6916cce90212
commented
10 years ago This is basically ready for review now, although there are a couple of areas in the docs where LaTex isn't rendering as we expected. If someone could take a quick look over this that would be great.
We believe we've incorporated all of the suggestions made, check Github to see any discussions we had.
Vince is going to be emailing the people that kcrisman recommended we talk to about reviewing and hopefully this should be ready very soon.
Once again, if there is anybody who is willing to take a look at getting the docs working it would be greatly appreciated.
drvinceknight
commented
10 years ago On an unrelated note, I'm wondering whether there happens to be any faster algorithms for calculating things - there is probably a literature of computational complexity and game theory, like there is in voting. Some of these combinatorial things (e.g. for coalitions) get really nasty really quickly.
To the best of my knowledge there isn't. There are various approximation algorithms that exist that could be coded in to here in the future perhaps?
I have updated my knowledge and we've just implemented a much better calculation that is more or less (to the best of my knowledge) as fast as one can go without taking advantage of particular structures of a particular case.: http://www.math.ucla.edu/~tom/Game_Theory/coal.pdf
James is reviewing my changes and will push to trac.
kcrisman
commented
10 years ago Awesome. I hope to have some time tomorrow to look at this and I would hope the Mathjax/LaTeX issue will be pretty easy to solve once I look at it.
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
d7553b0 | docs build as expected |
240761f | Merge branch '16332' of github.com:theref/sage-game-theory into 16332 |
33df3a0 | Have reordered things |
a2acb8f | Added some text |
a06b275 | fixes indentation error |
bf2bdeb | Have new implementation, going to get rid of redundant code |
a11d1a3 | Have removed now redundant functions |
8f97f9c | Tidied slightly |
5d50666 | Updated with new formulation |
9d0cc23 | removes redundant lines |
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago kcrisman
commented
10 years ago Here are a few brief comments to get going.
sage: integer_game.nullplayer?
Returns True if the current payoff_vector possesses the null player
property.
...is pretty minimalist.
$ ./sage -docbuild reference html
[dynamics ] WARNING: intersphinx inventory '/Users/.../sage/src/doc/output/html/en/reference/game_theory/objects.inv' not fetchable due to <type 'exceptions.IOError'>: [Errno 2] No such file or directory: Error building the documentation.This could just be my problem, of course.
:math: - see here, though I don't see anything obviously wrong.drvinceknight
commented
10 years ago Replying to @kcrisman:
Here are a few brief comments to get going.
- One thing I found odd - if you look at https://github.com/sagemath/sagetrac-mirror/blob/develop/src/doc/en/reference then you'll see that most modules only have a one-liner for the src/doc/en/reference/game_theory/conf.py type file. My guess is that is a good idea, though you'll want to try to make sure.
Thanks: we'll look in to this asap!
- Probably brief versions of the (great) descriptions of the methods in the main doctoring could be added to the individual method docs, e.g.
sage: integer_game.nullplayer? Returns True if the current payoff_vector possesses the null player property. ...is pretty minimalist.
Cool: will add these sorts of things asap.
- Documentation won't build, perhaps there is something needed in a manifest somewhere.
$ ./sage -docbuild reference html [dynamics ] WARNING: intersphinx inventory '/Users/.../sage/src/doc/output/html/en/reference/game_theory/objects.inv' not fetchable due to <type 'exceptions.IOError'>: [Errno 2] No such file or directory: Error building the documentation.This could just be my problem, of course.
- Are your LaTeX issues due to using dollar signs instead of single backticks? (Since I can't actually build the documentation.)
- Or, you may be interested in using the
:math:- see here, though I don't see anything obviously wrong.
The puzzlement continues with the docs: we'll do our best! Thanks :)
- If you are using a different source for Shapley, maybe you should mention your source. Also (though this is more minor, since this is a first try!), did you compare timings for the two different things in Python? Creating lots of power sets and factorials looks as scary as what you did before, but maybe it isn't.
Will add a reference. The number of calculations is severely reduced (n! vs 2^n -1) and I ran a couple of tests to check that it's indeed much faster. For example with the LONG example (value of a coalition is the size of coalition) it starts to take longer to create a game than to obtain the Shapley value...
Thanks for the comments: very much appreciated.
tscrim
commented
10 years ago Reviewer: Karl-Dieter Crisman, Travis Scrimshaw
tscrim
commented
10 years ago tscrim
commented
10 years ago Author: James Campbell, Vince Knight
tscrim
commented
10 years ago I've fixed up the documentation, both in formatting and content (there were a bunch of typos). So take a look, it has most types of formats that you'll ever need. I also simplified the computation of the Shapley value to use binomial, so we (generally) don't have to do large cancellations. With this change alone I got a 10~15% speedup, plus I did some other (micro)optimizations. I don't know the logic behind the math, but the code does what is stated in the doc and agrees with the reference. However if you could provide a reference for the alternative form of the Shapley value, then I think we can set this to a positive review as I think I've also addressed all of Karl-Dieter's comments.
New commits:
4745c46 | Merge branch 'u/jcampbell/game_theory__build_capacity_to_calculate_shapley_value_of_cooperative_games_' of trac.sagemath.org:sage into public/game_theory/Shapley_value_coop_games-16332 |
1352027 | Fixed up documentation and some other misc speedups. |
1d4cb93 | Adding additional doc to other functions. |
kcrisman
commented
10 years ago Thanks, Travis! I will still want to make sure to check a few things out myself, but I really appreciate you helping get this into shape, because I've had no time this week - being at a conference where I heard "Shapley value" many times :)
Vince and James, one way you can help now is by reviewing Travis' changes - do the docs look good now, was everything he said mathematically correct from your point of view, etc.
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago 7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago drvinceknight
commented
10 years ago Replying to @kcrisman:
Thanks, Travis! I will still want to make sure to check a few things out myself, but I really appreciate you helping get this into shape, because I've had no time this week - being at a conference where I heard "Shapley value" many times :)
Thanks a lot indeed Travis and Kris!
Vince and James, one way you can help now is by reviewing Travis' changes - do the docs look good now, was everything he said mathematically correct from your point of view, etc.
The docs look great, everything is indeed correct and I've added the reference as suggested.
Travis: thank you very much for the work you did on the docs: this is super helpful going forward (we're making very good progress on ticket 16333).
tscrim
commented
10 years ago Minor point, but we adopt the (pseudo) standard of having docstring lines being 80 (well 79) characters long. Other than that, if you think the docs are good, then I think we can set this to positive review.
Also I set this as finance since that is the closest component that game theory is connected too (in my somewhat uninitiated opinion, at least until someone adds a game theory tag
drvinceknight
commented
10 years ago Replying to @tscrim:
Minor point, but we adopt the (pseudo) standard of having docstring lines being 80 (well 79) characters long. Other than that, if you think the docs are good, then I think we can set this to positive review.
I was actually aware of this but my mistake if I missed some (apologies!). Has anyone written a script that checks the pep8-ish convention? That would be cool...
To clarify: is there anything else that James and I should/can do for this ticket at this point? (Not sure if flicking the switch to positive review is for us to do?).
Also I set this as finance since that is the closest component that game theory is connected too (in my somewhat uninitiated opinion, at least until someone adds a game theory tag
).
Great, thanks: how does one go about getting another tag included? It might make more sense once we have pushed our work for ticket 16333 (there's a bunch of cool stuff for normal form games coming there).
Thanks again both for your help. Really appreciative.
kcrisman
commented
10 years ago Tadah!
drvinceknight
commented
10 years ago Awesome: thanks!
tscrim
commented
10 years ago Replying to @drvinceknight:
Replying to @tscrim:
Minor point, but we adopt the (pseudo) standard of having docstring lines being 80 (well 79) characters long. Other than that, if you think the docs are good, then I think we can set this to positive review.
I was actually aware of this but my mistake if I missed some (apologies!). Has anyone written a script that checks the pep8-ish convention? That would be cool...
I don't know of any such tool, but I'd guess they are surely out there...
To clarify: is there anything else that James and I should/can do for this ticket at this point? (Not sure if flicking the switch to positive review is for us to do?).
Make sure my changes are good, and if so, then you can set a positive review.
Also I set this as finance since that is the closest component that game theory is connected too (in my somewhat uninitiated opinion, at least until someone adds a game theory tag
). Great, thanks: how does one go about getting another tag included?
Yay, new tag. Karl-Dieter, are you going to tell us how you do your magic? :P
kcrisman
commented
10 years ago Yay, new tag. Karl-Dieter, are you going to tell us how you do your magic? :P
Apparently I am a Trac admin. But I'll keep the details hush-hush so as not to abuse my new-found authority. Honestly, we probably have more components than we need, this was pretty unusual in really not even coming close to fitting anything else...
More to say:
I had thought about this for a while and agree that (A,) isn't the best. Just on this minor point, we thought about having a clean up in the init method that would handle A, (A,) as well as (A) but require (A,B) for two tuples etc... Is this a done thing?
So... what happened to that? I still find this syntax VERY onerous. Economists aren't necessarily interested in typing that many commas; the quotes are bad enough (though necessary, I think). There is a mention of this in a test but you don't exactly take advantage of it.
A characteristic
+ function game `G = (N, v)` is superadditive if it satisfies `v(C_2)
+ \geq v(C_1)` for all `C_1 \subseteq C_2` such that `C_1 \cap C_2 = \emptyset`.What the heck? (This is wrong in both places.)
where `S_{\pi}(i)` is the number of predecessors of `i` in `\pi`,The Shapley value (described above) is none to be the uniquesymmetric instead of symmetry?I trust Travis that this is all implemented correctly, however (but superadditive?) and in general I think you have something really worth adding to Sage here!
d3dfe940-4ef4-4242-81e0-6916cce90212
commented
10 years ago We have implemented a check such that if a user accidentally enters (1) it gets changed to (1,). Python automatically recognises that A, == (A,) anyway as tuples are defined by the commas and not the brackets. Is this sufficient or is some extra work required to make it more user friendly? Thanks for the comments though!
drvinceknight
commented
10 years ago Replying to @theref:
We have implemented a check such that if a user accidentally enters (1) it gets changed to (1,). Python automatically recognises that A, == (A,) anyway as tuples are defined by the commas and not the brackets. Is this sufficient or is some extra work required to make it more user friendly? Thanks for the comments though!
Should we perhaps include some docs showing that it's possible?
Thanks for the comments Karl, busy (with Dana and TJ actually!) right now but will get those changes done this evening :)
kcrisman
commented
10 years ago We have implemented a check such that if a user accidentally enters (1) it gets changed to (1,). Python automatically recognises that A, == (A,) anyway as tuples are defined by the commas and not the brackets.
What I mean is that perhaps the desired input method should be without commas. Vince's comment seems good - maybe one could include an example and then clarify where/when it would be suboptimal to use the (1) notation. I'm not worried about A, versus (A,) because most non-Python-gurus are not going to be putting the commas in!
Thanks for the comments Karl, busy (with Dana and TJ actually!) right now but will get those changes done this evening :)
No rush on my part - I heard from both of them about your adventure this week. Slightly jealous, but I hope you all have a great time and that some fruit comes of it!
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago Branch pushed to git repo; I updated commit sha1. New commits:
97f9f74 | fixes dfenition |
bf946fe | Added reference for fairness |
73637f3 | Added discussion about complexity of calculating the Shapley value |
a6bf320 | Merge branch '16332' of https://github.com/theref/sage-game-theory into 16332 |
a17192c | adds tuple docs |
8562845 | fixes other typos |
9ca69fc | changes is_symmetric |
128a4f9 | Some tweaks to docs |
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago drvinceknight
commented
10 years ago Replying to @kcrisman:
We have implemented a check such that if a user accidentally enters (1) it gets changed to (1,). Python automatically recognises that A, == (A,) anyway as tuples are defined by the commas and not the brackets.
What I mean is that perhaps the desired input method should be without commas. Vince's comment seems good - maybe one could include an example and then clarify where/when it would be suboptimal to use the
(1)notation. I'm not worried aboutA,versus(A,)because most non-Python-gurus are not going to be putting the commas in!
We had a long think about this and have included some text in the documentation to justify what is happening now. In particular we think that A alone should not necessarily be allowed as we don't really want to map A to a value but the set containing A...
Otherwise, pretty sure that we've addressed everything else you raised.
Thanks for the comments Karl, busy (with Dana and TJ actually!) right now but will get those changes done this evening :)
No rush on my part - I heard from both of them about your adventure this week. Slightly jealous, but I hope you all have a great time and that some fruit comes of it!
Not meaning to make you more jealous but it really was a great week, it was awesome to meet Dana and TJ: they're great! Sadly, I forgot the one in joke you told me about Dana, I seem to remember you telling me to ask him about something... Perhaps the next time the 3 of us will be in the same spot and you could remind me (I realise trac probably isn't the right place for this chat - apologies) :)
kcrisman
commented
10 years ago Okay. You still haven't fixed one of the superadditive documentation pieces. Otherwise I am happy though I will not be able to check doctests etc. in the next bit. Yay!
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
10 years ago
Include class for cooperative games, main goal is to be able to calculate Shapley value for characteristic function games.
Should be efficient to code in pure python/cython.
Component: game theory
Keywords: Cooperative Games
Author: James Campbell, Vince Knight
Branch/Commit:
95dcda1Reviewer: Karl-Dieter Crisman, Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/16332