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

12

13

14

15

16
(1) 
17

18

19

20

21
(1) 
22
(3) 
23
(3) 
24
(1) 
25
(1) 
26

27

28

29

30

31


From: Aaron Siegel <asiegel@Math.Berkeley.EDU>  20031025 20:58:33

I just added a slight enhancement to the language (not checked in yet.) setof can take an optional third argument, which specifies a condition for when a value should be added to the set. for example: setof(n+1, n=1..5, n != 3) would return [2,3,5,6] This makes possible the following function, which I think nicely illustrates the power of the language: subtgame = proc(lset, rset, n) { setof(subtgame(lset, rset, nlset[i]), i=0..Length(lset)1, nlset[i] >= 0)  setof(subtgame(lset, rset, nrset[i]), i=0..Length(rset)1, nrset[i] >= 0) } end; The procedure specifies an arbitrary partizan subtraction game (with finite subtraction sets for each player.) For example: subtgame([1,3,5,6],[2,3,4],20) is the value of a heap of size 20, where Left can remove 1, 3, 5 or 6 beans, and Right can remove 2, 3, or 4. Quite nifty! (Incidentally, this particular position is an infinitesimal of atomic weight 6.) One thing that's worth pointing out is that cgsuite currently uses 0based indexing for lists. Perhaps it should be switched to 1based lists to be consistent with Maple etc. Any opinions on this? I remember we had a discussion about it awhile back but I forget if we reached a consensus. If I voiced any opposition to 1based indexing then, I've since come around  particularly as functions can still take 0 as a parameter (or 1/2, ^^, "blue", or anything else for that matter.) Finally, the "subtgame" function could also be entered using functional notation as follows: subtgame = (lset, rset, n) > { setof(subtgame(lset, rset, nlset[i]), i=0..Length(lset)1, nlset[i] >= 0)  setof(subtgame(lset, rset, nrset[i]), i=0..Length(rset)1, nrset[i] >= 0) }; Aaron 
From: Aaron Siegel <asiegel@Math.Berkeley.EDU>  20031024 13:31:41

Ok, I've just checked in a preliminary version of the scripting language. No documentation yet, but everything is pretty much as per our discussions on this list. I'd be grateful to receive bug reports / suggestions if you get the urge to play around with it. I'm aware that many of the error messages display improperly. I'll hold off on releasing 0.4 until I'm convinced the new features are stable. The "Run Script ..." command might be broken, so I suggest typing scripts directly into the worksheet for now. (You can use shiftenter to insert a line break.) Here's two scripts that have been tested and work fine (and can be copy/pasted into the worksheet): for n from 1 to 10 do "Canonical form of 2x" + n + " domineering:" >> out; C(DomineeringRectangle(2,n)) >> out; od LL(0) = 1; LL(n_) = { setof(LL(i) + LL(ni1), i=0..n1)  setof(LR(i) + LR(ni1), i=0..n1) }; LR(n_) = { setof(LL(i) + LR(ni1), i=0..n1)  setof(LR(i) + RR(ni1), i=0..n1) }; RR(n_) = { setof(LR(i) + LR(ni1), i=0..n1)  setof(RR(i) + RR(ni1), i=0..n1) }; "Horizontal Blockbusting results through L20L:" >> out; t = CreateTable(4); AddTableRow(t, "n", "LnL", "LnR", "RnR"); for n from 0 to 20 do AddTableRow(t, n, LL(n), LR(n), RR(n)) od; t The Blockbusting script also works fine using the n > if n == 0 then 1 else ... fi notation. Note that base cases for LR and RR don't need to be specified explicitly, since they're subsumed into the general case (left and right have empty sets of options for L0R and R0R.) Enjoy! Aaron 
From: Aaron Siegel <asiegel@Math.Berkeley.EDU>  20031023 06:16:43

On Wed, 22 Oct 2003, David Wolfe wrote: > I guess I'd still vote for > SetOf(LL(i) + LL(ni1), i=0..n1) Ok. I'll go with "setof" rather than my originally suggested "SetOf", however, in order to maintain a distinction between keywords (lowercase) and methods (capitalized.) > I'd go for any of the first three. One advantage with > f(n_) = n + 1 > is that those users likely to use a tool but who are not programmers > may, very well, have used used mathematica. The disadvantage is that > Wolfram might find a way to take legal action... I should point out that they're equally likely to have used Maple, which uses the "f = n > n + 1" notation. But there's no harm in supporting both, and I agree that it's better to borrow notation that might be familiar to some people than to bring new notation into the world. I think it would be hard for Wolfram to show harm, since cgsuite is free software, and anyway you can't copyright an underscore :) (not yet, anyway . . .) > In any event, you could issue an appropriately helpful message if > someone types > f(n) = n+1 > such as "to define a function, use f(n_) = n+1" Good idea. When the user types "f(n) = expr" and n is undefined, I'll print a helpful suggestion rather than "Unrecognized identifier: n". But if n has been defined, I'll suppress the warning and assume the user knows what he's doing. Aaron 
From: David Wolfe <wolfe@ga...>  20031023 03:20:09

> Here's another alternative that just occurred to me, which might be more > natural: > setof(LL[i] + LL[ni1] for i from 0 to n1) I guess I'd still vote for SetOf(LL(i) + LL(ni1), i=0..n1) > I'd be happy with any of the following: > f(n:) = n + 1 > f(n_) = n + 1 > define f(n) = n + 1 > f(n) = def n + 1 > f(n) def = n + 1 > f(param n) = n + 1 > f = n > n + 1 I'd go for any of the first three. One advantage with f(n_) = n + 1 is that those users likely to use a tool but who are not programmers may, very well, have used used mathematica. The disadvantage is that Wolfram might find a way to take legal action... In any event, you could issue an appropriately helpful message if someone types f(n) = n+1 such as "to define a function, use f(n_) = n+1" I'm so glad you are coding up the programming language on top of cgsuite, and I'm confident I'll be quite happy with whatever the outcome of these thoughtful deliberations. David 
From: Aaron Siegel <asiegel@Math.Berkeley.EDU>  20031023 01:48:11

By using "acceptable" I meant simply to ask your opinion on whether this notation would adequately serve the proposed purpose; I didn't intend to imply anything more. Sorry for any confusion :) Here's another alternative that just occurred to me, which might be more natural: setof(LL[i] + LL[ni1] for i from 0 to n1) As for functions, Mathematica uses underscores: f(n_) = n+1 But I've always found that notation a bit odd. I understand that there is little need for a means of assigning f at the value of a preexisting variable; it's more a matter of minimizing ambiguity in the grammar. If the grammar is too ambiguous, I fear users will be left scratching their heads wondering why cgsuite is misinterpreting their input. My concern is this: Each of the following clearly assigns f at one specific value, and can have no other (reasonable) meaning: f(5) = 3 f(*) = 3 f(n+5) = 3 f((n)) = 3 and so on. It seems confusing to make "f(n) = 3" the sole exception: Then f(expr) = 3 would always mean "evaluate expr, then assign f the value 3 at that input", except in the one case when expr is a simple identifier. I'd be happy with any of the following: f(n:) = n + 1 f(n_) = n + 1 define f(n) = n + 1 f(n) = def n + 1 f(n) def = n + 1 f(param n) = n + 1 f = n > n + 1 Another alternative would be to use : (or some other distinguishing mark) to explicitly fill a value, as you suggest, but require it to be attached to *any* expression, not just to identifiers, e.g. f(0:) = f(1:) = 0; f(n) = f(n1) + f(n2); Aaron On Wed, 22 Oct 2003, David Wolfe wrote: > > Would any of the following be acceptable in place of the "where" notation? > > Do you have a preference among them? > > I'd say "acceptable" is an unusual choice of word, since doing nothing > about my suggestion is also "acceptable". But of the four choices, I > find > SetOf(LL(i) + LL(ni1), i=0..n1) > most natural. > > I guess I have a few meandering thoughts on the n: in > > f(n:) = f(n1) + f(n2); > I was hoping that the := used for assignment in place of = would (by > default) bind any variable which occurs on the RHS. Perhaps > > define f(n) = ... > > is more natural. Isn't there also a language that uses the _ much in > the same way as you wish to use the : ? > f(_n) = f(n1) + f(n2); > > > More substantively, it's hard for me to picture > someone writing f(n) = ... where the previous value of n previously > is relevant to the assignment. If you concur that it would be rare, > I'd be inclined to use the : to explicitly fill in the value of n. Or > f(value(n)) = ... > > David > > >  > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > cgsuitedevel mailing list > cgsuitedevel@... > https://lists.sourceforge.net/lists/listinfo/cgsuitedevel > 
From: David Wolfe <wolfe@ga...>  20031022 17:00:19

> Would any of the following be acceptable in place of the "where" notation? > Do you have a preference among them? I'd say "acceptable" is an unusual choice of word, since doing nothing about my suggestion is also "acceptable". But of the four choices, I find SetOf(LL(i) + LL(ni1), i=0..n1) most natural. I guess I have a few meandering thoughts on the n: in > f(n:) = f(n1) + f(n2); I was hoping that the := used for assignment in place of = would (by default) bind any variable which occurs on the RHS. Perhaps define f(n) = ... is more natural. Isn't there also a language that uses the _ much in the same way as you wish to use the : ? f(_n) = f(n1) + f(n2); More substantively, it's hard for me to picture someone writing f(n) = ... where the previous value of n previously is relevant to the assignment. If you concur that it would be rare, I'd be inclined to use the : to explicitly fill in the value of n. Or f(value(n)) = ... David 
From: Aaron Siegel <asiegel@Math.Berkeley.EDU>  20031022 05:00:02

Perhaps it's best to allow either notation. Functional definition: f = n > if n <= 1 then 1 else f(n1) + f(n2) fi; *or* Definition by cases: f(0) = f(1) = 1; f(n:) = f(n1) + f(n2); (I'm open to suggestions regarding the f(n:) notation, but there needs to be some way to distinguish syntactically from the situation where n is a preassigned variable with some fixed value.) For definition by cases, how about allowing only one general case, supplemented by arbitrarily many special cases? This would avoid the headaches associated with deciding which case applies when; it would be easy to implement and totally unambiguous, and still take care of the most common multicase situation. Special cases would *always* take precedence, regardless of when they were defined, so the above would be equivalent to: f(n:) = f(n1) + f(n2); f(0) = f(1) = 1; Would any of the following be acceptable in place of the "where" notation? Do you have a preference among them? Eval(LL(i) + LL(ni1), i, 0, n1) Eval(LL(i) + LL(ni1), i=0..n1) SetOf(LL(i) + LL(ni1), i, 0, n1) SetOf(LL(i) + LL(ni1), i=0..n1) Each would be equivalent to Eval(i > LL(i) + LL(ni1), 0, n1). Aaron On Tue, 21 Oct 2003, David Wolfe wrote: > I'll add my two cents, even though I'm way too distracted to think > about this as deeply as you guys have. Let me preface my one remark > by saying I would be very pleased indeed to have cgsuite support the > grammar as you've described with the postMichaelcomment improvements. > > While I like your notation for use by anyone who can code already, I'd > still be inclined to try to find a grammar which makes it possible for > nonprogramming mathematicians to do as much as possible. > > Wouldn't it be nice for nonprogrammers if the following were legal ? > > LL(0) := 1; > LR(0) := 0; > LL(0) := 0; > LL(n) := { LL(i) + LL(ni1) where 0 <= i < n  > LR(i) + LR(ni1) where 0 <= i < n }; > LR(n) := { LL(i) + LR(ni1) where 0 <= i < n  > LR(i) + RR(ni1) where 0 <= i < n }; > RR(n) := { LR(i) + RR(ni1) where 0 <= i < n  > RR(i) + RR(ni1) where 0 <= i < n }; > > OR > > LL(0) := 1; > LR(0) := 0; > LL(0) := 0; > LL(n) := { LL(i) + LL(ni1)  LR(i) + LR(ni1) } where 0 <= i < n ; > LR(n) := { LL(i) + LR(ni1)  LR(i) + RR(ni1) } where 0 <= i < n ; > RR(n) := { LR(i) + RR(ni1)  RR(i) + RR(ni1) } where 0 <= i < n ; > > David > > >  > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > cgsuitedevel mailing list > cgsuitedevel@... > https://lists.sourceforge.net/lists/listinfo/cgsuitedevel > 
From: David Wolfe <wolfe@ga...>  20031022 03:52:27

I'll add my two cents, even though I'm way too distracted to think about this as deeply as you guys have. Let me preface my one remark by saying I would be very pleased indeed to have cgsuite support the grammar as you've described with the postMichaelcomment improvements. While I like your notation for use by anyone who can code already, I'd still be inclined to try to find a grammar which makes it possible for nonprogramming mathematicians to do as much as possible. Wouldn't it be nice for nonprogrammers if the following were legal ? LL(0) := 1; LR(0) := 0; LL(0) := 0; LL(n) := { LL(i) + LL(ni1) where 0 <= i < n  LR(i) + LR(ni1) where 0 <= i < n }; LR(n) := { LL(i) + LR(ni1) where 0 <= i < n  LR(i) + RR(ni1) where 0 <= i < n }; RR(n) := { LR(i) + RR(ni1) where 0 <= i < n  RR(i) + RR(ni1) where 0 <= i < n }; OR LL(0) := 1; LR(0) := 0; LL(0) := 0; LL(n) := { LL(i) + LL(ni1)  LR(i) + LR(ni1) } where 0 <= i < n ; LR(n) := { LL(i) + LR(ni1)  LR(i) + RR(ni1) } where 0 <= i < n ; RR(n) := { LR(i) + RR(ni1)  RR(i) + RR(ni1) } where 0 <= i < n ; David 
From: Aaron Siegel <asiegel@Math.Berkeley.EDU>  20031021 18:20:17

Hi Michael, Thanks for your comments! Glad to see people are still following this list :) Dynamic resizing is a must, I agree. Your suggested use of holes is far superior to what I'd initially envisioned (filling empty indices with zeroes.) I too prefer the IsBound(list, index) syntax; it has the added advantage of introducing no new parser headaches. I also propose Clear(var) to clear an array (or other variable), permitting Clear(var1, var2, ...) I've proposed a default onelevel flattening in the specific case of definition by explicit option list. I understand this carries inherent risks but I think it's unlikely to cause serious confusion in this restricted circumstance, and the notation { GL  GR } seems to me quite intuitive. I much prefer your notation for functions to mine; among other things, it would be much easier to implement. I'll cache function values by default (regardless of notation), since I expect most cgsuite functions to be recursive. Adding a proc(v1,v2,...) directive similar to Maple's, to account for multiargument multistatement procedures, would entail little additional effort. A method for converting a function to a (finite) list would be nice, e.g.: Eval(f, 0, 3) This would return the list [f(0), f(1), f(2), f(3)]. Of course functions could take any object as a parameter (unlike lists, which are restricted to integer indices.) This notation gives the following quite clean description of Blockbusting: LL = n > if n == 0 then 1 else { Eval(i > LL(i) + LL(ni1), 0, n1)  Eval(i > LR(i) + LR(ni1), 0, n1) } fi; LR = n > { Eval(i > LL(i) + LR(ni1), 0, n1)  Eval(i > LR(i) + RR(ni1), 0, n1) }; RR = n > { Eval(i > LR(i) + RR(ni1), 0, n1)  Eval(i > RR(i) + RR(ni1), 0, n1) }; Then LL(n), LR(n) and RR(n) would calculate the positions LnL, LnR and RnR in (horizontal) blockbusting. Quite clean and natural, I think! Aaron On Mon, 20 Oct 2003, Michael Albert wrote: > > > > > Of course there is more to be done; for example, there need to be > > nice > > ways to manipulate (construct, populate, etc.) collections and > > arrays. > > Any thoughts on how to handle this? > > > > I've been using GAP extensively while on sabbatical here at St. Andrews. > The language syntax is (for well understood historical reasons) also very > close to Maple. They have a nice treatment of arrays which I think would > work well for games too. Basically they implement dynamically resizable > arrays which allows clean definitions like: > > aList := []; > aList[5] := 3; > > Now if we ask to see aList: > > [,,,,3] (one based indexing) > > The empty spaces are referred to as holes. The key utility function > (needed for an indexing for loop over a list which may have holes and > indirectly for an "in" style loop) is > > IsBound(aList[index]) > > which returns a boolean indicating whether or not that index has been > bound. (I must confess the syntax bothers me a little, I would prefer > IsBound(aList, index) > > > Also, right now the only way to specify options for a game is to list > > them > > explicitly; a facility for specifiying *collections* of left and > > right > > options is essential. Perhaps the best way to handle this is just to > > allow collections within braces, so for example > > > > { 0,[*,*2]  0 } > > > > would have the same meaning as > > > > { 0,*,*2  0 } > > > > That is, a default flattening? A bit risky perhaps, but probably not. Is > the Maple approach of having to remember to say "op(aList)" in order to > convert a collection into its sequence of values problematic? > > > Finally, as David suggested long ago, it would be nice if one could > > define > > an array recursively. This is a trickier task, both from a design > > and > > implementation perspective, and maybe should be deferred until later. > > Here's a preliminary proposal for the syntax: > > > > identifier "[" identifier ":" (expression)? "]" "=" expression > > > > For example: > > > > f[n : n <= 1] = 1; > > f[n : n > 1] = f[n1] + f[n2]; > > > > This would specify the fibonnaci sequence. The condition is optional; > > the > > presence of the colon indicates that a recursive definition is being > > made. > > This distinguishes between the following two constructions: > > > > a[n] = C(DomineeringRectangle(2,n)); > > a[n:] = C(DomineeringRectangle(2,n)); > > > > The first assumes that n has already been defined, and immediately > > calculates the value of 2xn domineering; the second defines a[n] for > > all > > n, but defers any evaluation. > > > > Aaron > > > > > > My mathematical training asserts that what we were really talking about in > the second example is a function. I'd prefer to see: > > a := n > C(DomineeringRectangle(2,n)); > > and in the preceding example: > > f := n > if (n <= 1) then 1 else f(n1) + f(n2) fi; > > although the "earlier definitions take precedence" rule would allow the > aesthetically more pleasant: > > f(0) := 1; > f(1) := 1; > f := n > f(n1) + f(n2); > > I realise that the array approach means that the values will be cashed > automatically, while this is not clear in the functional approach  but > again Maple offers "option remember" as a possible solution. > >  > Michael H. Albert malbert@... > Senior Lecturer, (Ph) 6434798586 > Department of Computer Science, (Fx) 6434798529 > University of Otago, Dunedin > NEW ZEALAND > 
From: Aaron Siegel <asiegel@Math.Berkeley.EDU>  20031016 23:29:47

Ok, I've been promising this email for months now  I've finally found time to start working on language enhancements for cgsuite. My instinct is to follow straight Maple syntax, since it is simple and familiar. Here's a first stab at a grammar (comments appreciated, as always): statementseq: statement (SEMICOLON (statementseq)?)? statement: expression  "if" expression "then" statementseq ("elif" expression "then" statementseq)* ("else" statementseq)? "fi"  ("for" identifier)? ("from" expression)? ("to" expression)? ("by" expression)? ("while" expression)? "do" statementseq "od"  "for" identifier "in" expression "do" statementseq "od"  "break" An expression in an if/elif/while conditional must evaluate to a Boolean. An expression in a for/from/to/by loop can evaulate to any CanonicalGame; this leaves open such possibilities as for g from 0 to {64} by {20} do ... od; The expression in a for/in loop must evaluate to a list, e.g. for g in LeftOptions(h) do ... od; I also propose keywords "and", "or" and "not" with obvious meanings. Standard evaluationorder semantics apply, so true or C(DomineeringRectangle(100,100)) == 0 would quickly return true. As an example, the following would print out the values of 2xn domineering for n=1..8: for n to 8 do C(DomineeringRectangle(2,n)) >> out od; Of course there is more to be done; for example, there need to be nice ways to manipulate (construct, populate, etc.) collections and arrays. Any thoughts on how to handle this? Also, right now the only way to specify options for a game is to list them explicitly; a facility for specifiying *collections* of left and right options is essential. Perhaps the best way to handle this is just to allow collections within braces, so for example { 0,[*,*2]  0 } would have the same meaning as { 0,*,*2  0 } Finally, as David suggested long ago, it would be nice if one could define an array recursively. This is a trickier task, both from a design and implementation perspective, and maybe should be deferred until later. Here's a preliminary proposal for the syntax: identifier "[" identifier ":" (expression)? "]" "=" expression For example: f[n : n <= 1] = 1; f[n : n > 1] = f[n1] + f[n2]; This would specify the fibonnaci sequence. The condition is optional; the presence of the colon indicates that a recursive definition is being made. This distinguishes between the following two constructions: a[n] = C(DomineeringRectangle(2,n)); a[n:] = C(DomineeringRectangle(2,n)); The first assumes that n has already been defined, and immediately calculates the value of 2xn domineering; the second defines a[n] for all n, but defers any evaluation. Aaron 