You can subscribe to this list here.
2003 
_{Jan}

_{Feb}
(36) 
_{Mar}
(38) 
_{Apr}
(13) 
_{May}
(11) 
_{Jun}
(11) 
_{Jul}
(29) 
_{Aug}

_{Sep}

_{Oct}
(10) 
_{Nov}
(1) 
_{Dec}
(10) 

2004 
_{Jan}
(1) 
_{Feb}

_{Mar}
(2) 
_{Apr}
(4) 
_{May}
(2) 
_{Jun}
(9) 
_{Jul}

_{Aug}

_{Sep}
(3) 
_{Oct}

_{Nov}

_{Dec}
(2) 
2005 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(1) 
_{Nov}
(5) 
_{Dec}

2006 
_{Jan}

_{Feb}

_{Mar}
(30) 
_{Apr}
(12) 
_{May}
(3) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}
(5) 
_{Oct}
(79) 
_{Nov}
(36) 
_{Dec}
(54) 
2007 
_{Jan}

_{Feb}
(22) 
_{Mar}
(11) 
_{Apr}
(5) 
_{May}
(24) 
_{Jun}

_{Jul}
(3) 
_{Aug}
(20) 
_{Sep}
(16) 
_{Oct}

_{Nov}

_{Dec}
(3) 
2008 
_{Jan}
(5) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2011 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(12) 
_{Aug}
(122) 
_{Sep}
(10) 
_{Oct}
(8) 
_{Nov}
(5) 
_{Dec}
(13) 
2012 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2

3

4

5

6

7

8

9

10

11
(4) 
12
(2) 
13
(2) 
14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31






From: <rjn@ma...>  20111013 10:01:11

Ordinal sum has cropped up in the analysis of sufficiently many games in the last few years as a that I agree it should be included in the hierarchy. I'm also happy with the proposed order. I'm nervous enough that I tend to use brackets even when not needed. Pity to lose `:' for use in loopy games though. Richard > exponentiation > ordinal sum > unary negation > multiplication, division, modulus > addition, subtraction > > Thanks for the loopy example. > > Neil 
From: Neil McKay <themckayguy@gm...>  20111013 06:18:24

I'm happy with (1:2)*3 and the proposed order: exponentiation ordinal sum unary negation multiplication, division, modulus addition, subtraction Thanks for the loopy example. Neil On Wed, Oct 12, 2011 at 2:08 AM, Aaron Siegel <aaron.n.siegel@...> wrote: > If unary negation has the same precedence as binary subtraction, one > consequence is that > > * : 1 > > is illegal  you'd have to type > > * : (1) > > instead. > > But there's a much bigger concern: it's contrary to the convention used by > C, Java, and most other languages that I'm familiar with. For example, Java > very specifically assigns higher precedence to unary negation than > multiplication: > > http://bmanolov.free.fr/javaoperators.php > > This is a very wellestablished convention, and I'm extremely reluctant to > go against it. Out of curiosity I just looked up a few other languages, and > Ruby and Python both use the same precedence as C and Java: (unary negation) >> (multiplication, division) > (binary addition, subtraction). It's really > quite rare to find a language principle on which C, Java, Ruby and Python > all happen to agree :) So I think the rationale would have to be > extraordinarily compelling to justify breaking this convention. I don't see > that here, so I think it's pretty clear that we want to preserve the same > relative ranking of these three operator types. > > Interestingly, Python has a builtin exponentiation primitive, and solves > the "2^4 problem" exactly the same way as cgsuite: by assigning > exponentiation higher precedence than unary negation. I'm now pretty > convinced that the ranking of the "standard" arithmetic operators currently > implemented by cgsuite is correct, i.e., strongest to weakest: > > exponentiation > unary negation > multiplication, division, modulus > addition, subtraction > > This leaves only the question of where ordinal sum should be placed  a > question that obviously has no parallel in the other languages. If it's > weaker than multiplication (as in my original proposal), then it's > necessarily weaker than unary negation  I don't see any way around this. > But there's another possibility: > > exponentiation > ordinal sum > unary negation > multiplication, division, modulus > addition, subtraction > > This means 1:2*3 > > would parse as > > (1:2)*3 > > rather than 1:(2*3). This seems a bit undesirable, since we have a type of > sum preceding a type of product. But it's the only way to get ordinal sum > to precede unary negation while still adhering to the established precedence > among the other operators. > > Re loopy games: a "pass" keyword exists! For example > > {*pass} > > is equivalent to > > a:{*a} > > This works for any plumtree, but more complicated loopy games still need > something akin to the : operator. For example, a 1point ko > > a:{1a0} > > can't be entered using "pass". > > On Tue, Oct 11, 2011 at 7:10 PM, Neil McKay <themckayguy@...> wrote: >> >> I'm more likely to write 1:1 wanting 1/2 than 2; which seems to >> disagree with Michael. On the other hand, if I wrote g:h I would want >> (g:h). Overall, I agree with Michael. >> >> As regards loopy games, can we implement a "pass" move? If so, does >> that largely do away with the need for the use of : in loopy games. >> >> Neil >> >> On Tue, Oct 11, 2011 at 3:16 PM, Michael Albert <malbert@...> >> wrote: >> >> >> >> 1. Relative operator precedence of unary negation. >> > >> > (much sensible stuff snipped in order to make room for soapbox) >> > >> > I suspect that I am in a minority here, but I have always thought that >> > unary negation should be treated as 'morally' the same as subtraction, >> > i.e. x is effectively shorthand for >> > >> > 0  x >> > >> > (I know this doesn't parse in most cases, but it's a mental model not a >> > parser). >> > >> > So I'd strongly prefer: >> > >> > 1:g to mean  (1:g) >> > >> > which also makes the inconsistency go away. >> > >> > But I'm also somewhat with David here. As a practitioner of defensive >> > bracketing in almost all the code I write in almost every language, >> > it's not likely to affect me. >> > >> > M >> > >> > >> > >> >  >> > Associate Professor Michael Albert >> > Dept. of Computer Science >> > University of Otago, PO Box 56 >> > Dunedin 9054, New Zealand >> > >> > (Ph) +64 3 479 8586 (Fx) +64 3 479 8529 >> > >> > >> >  >> > All the data continuously generated in your IT infrastructure contains a >> > definitive record of customers, application performance, security >> > threats, fraudulent activity and more. Splunk takes this data and makes >> > sense of it. Business sense. IT sense. Common sense. >> > http://p.sf.net/sfu/splunkd2doct >> > _______________________________________________ >> > cgsuitedevel mailing list >> > cgsuitedevel@... >> > https://lists.sourceforge.net/lists/listinfo/cgsuitedevel >> > > > 
From: Aaron Siegel <aaron.n.siegel@gm...>  20111012 05:09:02

If unary negation has the same precedence as binary subtraction, one consequence is that * : 1 is illegal  you'd have to type * : (1) instead. But there's a much bigger concern: it's contrary to the convention used by C, Java, and most other languages that I'm familiar with. For example, Java very specifically assigns higher precedence to unary negation than multiplication: http://bmanolov.free.fr/javaoperators.php This is a very wellestablished convention, and I'm extremely reluctant to go against it. Out of curiosity I just looked up a few other languages, and Ruby and Python both use the same precedence as C and Java: (unary negation) > (multiplication, division) > (binary addition, subtraction). It's really quite rare to find a language principle on which C, Java, Ruby and Python all happen to agree :) So I think the rationale would have to be extraordinarily compelling to justify breaking this convention. I don't see that here, so I think it's pretty clear that we want to preserve the same relative ranking of these three operator types. Interestingly, Python has a builtin exponentiation primitive, and solves the "2^4 problem" exactly the same way as cgsuite: by assigning exponentiation higher precedence than unary negation. I'm now pretty convinced that the ranking of the "standard" arithmetic operators currently implemented by cgsuite is correct, i.e., strongest to weakest: exponentiation unary negation multiplication, division, modulus addition, subtraction This leaves only the question of where ordinal sum should be placed  a question that obviously has no parallel in the other languages. If it's weaker than multiplication (as in my original proposal), then it's necessarily weaker than unary negation  I don't see any way around this. But there's another possibility: exponentiation ordinal sum unary negation multiplication, division, modulus addition, subtraction This means 1:2*3 would parse as (1:2)*3 rather than 1:(2*3). This seems a bit undesirable, since we have a type of sum preceding a type of product. But it's the only way to get ordinal sum to precede unary negation while still adhering to the established precedence among the other operators. Re loopy games: a "pass" keyword exists! For example {*pass} is equivalent to a:{*a} This works for any plumtree, but more complicated loopy games still need something akin to the : operator. For example, a 1point ko a:{1a0} can't be entered using "pass". On Tue, Oct 11, 2011 at 7:10 PM, Neil McKay <themckayguy@...> wrote: > I'm more likely to write 1:1 wanting 1/2 than 2; which seems to > disagree with Michael. On the other hand, if I wrote g:h I would want > (g:h). Overall, I agree with Michael. > > As regards loopy games, can we implement a "pass" move? If so, does > that largely do away with the need for the use of : in loopy games. > > Neil > > On Tue, Oct 11, 2011 at 3:16 PM, Michael Albert <malbert@...> > wrote: > >> > >> 1. Relative operator precedence of unary negation. > > > > (much sensible stuff snipped in order to make room for soapbox) > > > > I suspect that I am in a minority here, but I have always thought that > > unary negation should be treated as 'morally' the same as subtraction, > > i.e. x is effectively shorthand for > > > > 0  x > > > > (I know this doesn't parse in most cases, but it's a mental model not a > parser). > > > > So I'd strongly prefer: > > > > 1:g to mean  (1:g) > > > > which also makes the inconsistency go away. > > > > But I'm also somewhat with David here. As a practitioner of defensive > > bracketing in almost all the code I write in almost every language, > > it's not likely to affect me. > > > > M > > > > > > > >  > > Associate Professor Michael Albert > > Dept. of Computer Science > > University of Otago, PO Box 56 > > Dunedin 9054, New Zealand > > > > (Ph) +64 3 479 8586 (Fx) +64 3 479 8529 > > > > >  > > All the data continuously generated in your IT infrastructure contains a > > definitive record of customers, application performance, security > > threats, fraudulent activity and more. Splunk takes this data and makes > > sense of it. Business sense. IT sense. Common sense. > > http://p.sf.net/sfu/splunkd2doct > > _______________________________________________ > > cgsuitedevel mailing list > > cgsuitedevel@... > > https://lists.sourceforge.net/lists/listinfo/cgsuitedevel > > > 
From: Neil McKay <themckayguy@gm...>  20111012 02:10:46

I'm more likely to write 1:1 wanting 1/2 than 2; which seems to disagree with Michael. On the other hand, if I wrote g:h I would want (g:h). Overall, I agree with Michael. As regards loopy games, can we implement a "pass" move? If so, does that largely do away with the need for the use of : in loopy games. Neil On Tue, Oct 11, 2011 at 3:16 PM, Michael Albert <malbert@...> wrote: >> >> 1. Relative operator precedence of unary negation. > > (much sensible stuff snipped in order to make room for soapbox) > > I suspect that I am in a minority here, but I have always thought that > unary negation should be treated as 'morally' the same as subtraction, > i.e. x is effectively shorthand for > > 0  x > > (I know this doesn't parse in most cases, but it's a mental model not a parser). > > So I'd strongly prefer: > > 1:g to mean  (1:g) > > which also makes the inconsistency go away. > > But I'm also somewhat with David here. As a practitioner of defensive > bracketing in almost all the code I write in almost every language, > it's not likely to affect me. > > M > > > >  > Associate Professor Michael Albert > Dept. of Computer Science > University of Otago, PO Box 56 > Dunedin 9054, New Zealand > > (Ph) +64 3 479 8586 (Fx) +64 3 479 8529 > >  > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunkd2doct > _______________________________________________ > cgsuitedevel mailing list > cgsuitedevel@... > https://lists.sourceforge.net/lists/listinfo/cgsuitedevel > 
From: Michael Albert <malbert@cs...>  20111011 18:16:14

> > 1. Relative operator precedence of unary negation. (much sensible stuff snipped in order to make room for soapbox) I suspect that I am in a minority here, but I have always thought that unary negation should be treated as 'morally' the same as subtraction, i.e. x is effectively shorthand for 0  x (I know this doesn't parse in most cases, but it's a mental model not a parser). So I'd strongly prefer: 1:g to mean  (1:g) which also makes the inconsistency go away. But I'm also somewhat with David here. As a practitioner of defensive bracketing in almost all the code I write in almost every language, it's not likely to affect me. M  Associate Professor Michael Albert Dept. of Computer Science University of Otago, PO Box 56 Dunedin 9054, New Zealand (Ph) +64 3 479 8586 (Fx) +64 3 479 8529 
From: David Wolfe <davidgameswolfe@gm...>  20111011 17:12:01

When it's not obvious which way an expression should parse, one additional option is to error out w/ somes sort of "parens required" message. Yes, I know that isn't a popular view and expect to have the view discarded... David On Tue, Oct 11, 2011 at 1:33 PM, Aaron Siegel <aaron.n.siegel@...>wrote: > Neil has been making a forceful case for using : for ordinal sum. I've > thought about this quite a lot and I'm now leaning towards this change... so > typing > > *:2 > > would be equivalent to *.OrdinalSum(2). There are a couple of caveats and > corner cases; I'd welcome feedback on them: > > 1. Relative operator precedence of unary negation. What should be the > meaning of 1:^ (say)? Is it (1):^ or (1:^)? I think the former is most > natural. However, it also seems natural that 11:^ be parsed as 1(1:^). > This is a slight inconsistency that I guess is ok, but we need to be clear > and conscious about it. > > A similar issue arises with exponentiation; how should 2^4 be parsed? > Here it seems like the opposite convention is most natural; that is, this > should be (2^4). (Typing 2^4 and getting +16 as an answer would be > horribly confusing..) Another inconsistency that should probably just be > overlooked for the sake of naturality. > > Parsing issues with unary negation are a familiar problem in programming > languages; but in most languages they're not such a big deal  because the > principal issue is the interaction between negation and multiplication, and > negation commutes with multiplication. So you get the same answer > regardless of how it's parsed. > > To summarize, the proposal for operator precedence is (from strongest to > weakest) > > exponentiation > unary negation > multiplication (and division, modulus) > ordinal sum > disjunctive sum (and difference) > > A downside is that, by ranking exponentiation above unary negation, > expressions like 2^4 will get a parse error (requiring 2^(4) instead). > But I think this is preferential to parsing 2^4 as (2)^4. > > 2. Canonical simplification. Ordinal sum is not independent of form. This > means you might get an unexpected result in certain cases. For example, > typing > > {**} : 1 > > (say) will give the answer 1, rather than ^. This is because cgsuite first > simplifies {**} to 0 and then evaluates the ordinal sum. My intent is to > punt on this issue until a later version and eventually introduce a > "literal" operator. Then typing > > literal{**} > > will mean "the exact form {**}  don't simplify it" and so you can type > > (literal{**} : 1).CanonicalForm > > to get the "right" answer. Again, I don't plan to implement this in 1.0. > > 3. Loopy game construction. The current use of : is to specify loopy > games, in expressions like > > a:{*a} > > which defines the game G = {*G}. If we're appropriating : for ordinal > sum, then it obviously can't be used for this purpose anymore. I'm > deferring the bulk of loopy games support until a later version anyway, so I > might just punt on this one too. (This means that in 1.0, there will be no > way to enter loopy games.) > > It's reasonable to simply substitute another character here, such as # or > @, but I'm inclined to defer this decision until a later release. > > >  > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunkd2doct > _______________________________________________ > cgsuitedevel mailing list > cgsuitedevel@... > https://lists.sourceforge.net/lists/listinfo/cgsuitedevel > > 
From: Aaron Siegel <aaron.n.siegel@gm...>  20111011 16:33:13

Neil has been making a forceful case for using : for ordinal sum. I've thought about this quite a lot and I'm now leaning towards this change... so typing *:2 would be equivalent to *.OrdinalSum(2). There are a couple of caveats and corner cases; I'd welcome feedback on them: 1. Relative operator precedence of unary negation. What should be the meaning of 1:^ (say)? Is it (1):^ or (1:^)? I think the former is most natural. However, it also seems natural that 11:^ be parsed as 1(1:^). This is a slight inconsistency that I guess is ok, but we need to be clear and conscious about it. A similar issue arises with exponentiation; how should 2^4 be parsed? Here it seems like the opposite convention is most natural; that is, this should be (2^4). (Typing 2^4 and getting +16 as an answer would be horribly confusing..) Another inconsistency that should probably just be overlooked for the sake of naturality. Parsing issues with unary negation are a familiar problem in programming languages; but in most languages they're not such a big deal  because the principal issue is the interaction between negation and multiplication, and negation commutes with multiplication. So you get the same answer regardless of how it's parsed. To summarize, the proposal for operator precedence is (from strongest to weakest) exponentiation unary negation multiplication (and division, modulus) ordinal sum disjunctive sum (and difference) A downside is that, by ranking exponentiation above unary negation, expressions like 2^4 will get a parse error (requiring 2^(4) instead). But I think this is preferential to parsing 2^4 as (2)^4. 2. Canonical simplification. Ordinal sum is not independent of form. This means you might get an unexpected result in certain cases. For example, typing {**} : 1 (say) will give the answer 1, rather than ^. This is because cgsuite first simplifies {**} to 0 and then evaluates the ordinal sum. My intent is to punt on this issue until a later version and eventually introduce a "literal" operator. Then typing literal{**} will mean "the exact form {**}  don't simplify it" and so you can type (literal{**} : 1).CanonicalForm to get the "right" answer. Again, I don't plan to implement this in 1.0. 3. Loopy game construction. The current use of : is to specify loopy games, in expressions like a:{*a} which defines the game G = {*G}. If we're appropriating : for ordinal sum, then it obviously can't be used for this purpose anymore. I'm deferring the bulk of loopy games support until a later version anyway, so I might just punt on this one too. (This means that in 1.0, there will be no way to enter loopy games.) It's reasonable to simply substitute another character here, such as # or @, but I'm inclined to defer this decision until a later release. 
From: Aaron Siegel <aaron.n.siegel@gm...>  20111011 16:20:53

I'm finally responding to this... 1 & 2 are features that I've hoped to see in cgsuite for a long time. 3 would be welcome also  note that it would also provide a way to *verify* the canonical form quickly since we could presumably run the search algorithm over G  K (where K is the putative canonical form), as well as check whether G is infinitesimal etc. I could also envision (relatively) fast algorithms for computing mean and temperature, etc. I'm fine with the change proposed by 4 (ReducedCanonicalForm instead of Rcf)... anyone else have a preference here? I have a strong preference for "iterator" in place of "iterators". I'm going to go ahead and make this change. On Tue, Sep 27, 2011 at 11:43 PM, Neil McKay <themckayguy@...> wrote: > Hi all, > > I have many ideas about/for cgsuite that I've collected and want to share > below. I might try to tackle some of these but I'm not claiming any of them > for myself right now. > > 1) combgames.sty compatible LaTeX output. It would be great to have cgsuite > output code for immediate insertion into documents, including game trees, > tables and boards. > > 2) Graphs. Many combinatorial games are played on arbitrary graphs (or at > least planar graphs). I'd like to be able to use cgsuite and the explorer > for graph games, and perhaps functionality for grid games like NoGo where > positional equivalence may be more efficiently determined by considering the > game on a graph. > > 3) Computing the outcome class of a game quickly without having to find the > canonical form (you get the value for free, if the outcome is P!) > > 4) As much as typing ReducedCanonicalForm would be a hassle, it seems > inconsistent to have .CanonicalForm and .Rcf > > 5) I'll probably make an enemy of Michael for saying this, but directories > such as 'iterators' should probably just be 'iterator' so as to be > consistent with the 'game' directory. > > 6) There are lots of good methods waiting to be programmed for numbers, > some of which include binary represenations, hackenbush representations and > efficient calls for the numerator and denominator of a dyadic. > > 7) Program Nimstring (hopefully in the explorer). > > Neil > > >  > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunkd2dcopy1 > _______________________________________________ > cgsuitedevel mailing list > cgsuitedevel@... > https://lists.sourceforge.net/lists/listinfo/cgsuitedevel > > 