cgsuite-devel — CGSuite Development Issues

Re: [cgsuite-devel] CGSuite 1.0

[Neil A. M. <the...@gm...>]

I have follow-up comments on another GNU/Linux install.

Again I have tried some installing, but on a different distribution. I
think the things to do for a smooth install are: run as root, and empty
your equivalent of /home/nmckay/CGSuite first, as well as your .CGSuite
directory, which may contain preferences from whatever you have
installed already.
This time, I also had to chown .CGSuite/dev to nmckay  (from root) for
1.0 to load without trouble. At some point in my many tries to figure
out what was going on, I also received a warning about startup.cgs not
being found, but putting an empty startup.cgs in /home/nmckay/CGSuite
solved that. In the end it was replaced by the expected initial
startup.cgs. I now have 1.0 and the devel build running nicely along
side each other and the preferences seem not to interfere with each other.

Neil


On 11-12-03 05:56 PM, Neil McKay wrote:
> Hi Aaron,
> 
> I have some comments about installation on GNU/Linux.
> 
> I first tried to install as non-root, and during the install it was
> noted that /home/nmckay/CGSuite was not empty. I deleted it and moved
> on. Everything proceeded as normal, but when I ran CGSuite it couldn't
> find startup.cgs (in fact, I think CGSuite installed itself in
> /home/nmckay/CGSuite).
> 
> Next I installed on another machine, but first removing
> /home/nmckay/CGSuite. I installed as root, and the install went fine,
> but I had trouble after running the program as non-root, because there
> was trouble accessing /home/nmckay/.CGSuite/dev
> I removed the directory .CGSuite and then it loaded fine, and continues to.
> 
> I just installed as root on a machine that has not had CGSuite 1.0
> installed, and everything worked fine with the installer launching the
> program the first time.
> 
> Summary: I had trouble, but I think it was all related to my NetBeans
> version having been installed already. Also, the uninstaller works
> fine.
> 
> Neil
> 
> On Fri, Dec 2, 2011 at 7:49 PM, Aaron Siegel <aar...@gm...> wrote:
>> I just released CGSuite 1.0 !  You can download a copy at
>>
>> http://www.cgsuite.org/
>>
>> I strongly recommend installing a copy from the standard distribution of
>> CGSuite for "everyday" (non-development) use.  The distributions provide
>> much better integration with the operating system (you don't have to go
>> through NetBeans to run CGSuite, etc.)
>>
>> If you experience any problems with the installation, please let me know...
>> thanks!
>>
>> ------------------------------------------------------------------------------
>> 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. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> cgsuite-devel mailing list
>> cgs...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>>

Re: [cgsuite-devel] Some new features

[Neil M. <the...@gm...>]

Thanks for all those implementations, each is greatly appreciated.

Here are my thoughts on the loopy syntax:

I'd rather not the backtick because it isn't noisy enough (isn't
different enough from ', perhaps especially in some fonts).

I can see arguments against it, but if we are moving the operator out
front I think we can use &.

Is ? anything? I can see the benefits of reserving that usage for help
functions though.

I like @, I think it says "loopy game a referencing itself" quite nicely.

Neil

On Fri, Dec 23, 2011 at 6:31 PM, Aaron Siegel <aar...@gm...> wrote:
> I'd also prefer to settle on one syntax, and stick with it.  I find the use
> of a keyword cumbersome here - I'd prefer to use a symbol.  Various
> possibilities are
>
> Sharp:
> #a{a|0}
>
> Backtick:
> `a{a|0}
>
> Single quote:
> 'a{a|0}
>
> At:
> @a{a|0}
>
> Underscore:
> _a{a|0}
>
> I like David's suggestion of putting the symbol *before* the node label,
> rather than between the node label and the game specifier.  I always found
> 0.7's syntax (a:{0|a}) a bit clunky... I prefer any of the above to it.
>
> Of the above four choices, I guess I like the backtick the best... # and @
> are too "noisy" (too much distracting "ink"); single quote is too useful
> (e.g., in explicit game specifiers, per my previous email); and between `
> and _ I just like ` better...
>
>
> On Fri, Dec 23, 2011 at 12:38 PM, David Wolfe <dav...@gm...>
> wrote:
>>
>>
>>> (I also admit to a sneaky admiration for languages in which there is
>>> more than one allowed syntax for the same concept when appropriate,
>>> and would see no problem in having both this syntax and a more compact
>>> form.)
>>
>>
>> And I have sneaky disdain for same.  The problem is that a year or two
>> down the road, what Aaron decides is the right syntax will be recycled as
>> standard on blackboards or textbooks.  And I'd rather there be as few
>> standards as possible.
>>
>> The computer isn't the only audience.
>>
>> David
>>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> cgsuite-devel mailing list
> cgs...@li...
> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>

Re: [cgsuite-devel] Some new features

[Aaron S. <aar...@gm...>]

I'd also prefer to settle on one syntax, and stick with it.  I find the use
of a keyword cumbersome here - I'd prefer to use a symbol.  Various
possibilities are

Sharp:
#a{a|0}

Backtick:
`a{a|0}

Single quote:
'a{a|0}

At:
@a{a|0}

Underscore:
_a{a|0}

I like David's suggestion of putting the symbol *before* the node label,
rather than between the node label and the game specifier.  I always found
0.7's syntax (a:{0|a}) a bit clunky... I prefer any of the above to it.

Of the above four choices, I guess I like the backtick the best... # and @
are too "noisy" (too much distracting "ink"); single quote is too useful
(e.g., in explicit game specifiers, per my previous email); and between `
and _ I just like ` better...

On Fri, Dec 23, 2011 at 12:38 PM, David Wolfe <dav...@gm...>wrote:

>
> (I also admit to a sneaky admiration for languages in which there is
>> more than one allowed syntax for the same concept when appropriate,
>> and would see no problem in having both this syntax and a more compact
>> form.)
>>
>
> And I have sneaky disdain for same.  The problem is that a year or two
> down the road, what Aaron decides is the right syntax will be recycled as
> standard on blackboards or textbooks.  And I'd rather there be as few
> standards as possible.
>
> The computer isn't the only audience.
>
> David
>
>

Re: [cgsuite-devel] Some new features

[David W. <dav...@gm...>]

> (I also admit to a sneaky admiration for languages in which there is
> more than one allowed syntax for the same concept when appropriate,
> and would see no problem in having both this syntax and a more compact
> form.)
>

And I have sneaky disdain for same.  The problem is that a year or two down
the road, what Aaron decides is the right syntax will be recycled as
standard on blackboards or textbooks.  And I'd rather there be as few
standards as possible.

The computer isn't the only audience.

David

Re: [cgsuite-devel] Some new features

[Michael A. <ma...@cs...>]

How about using an actual operator name (rather than symbol) "as" comes to mind.

a as {0|a}

(I also admit to a sneaky admiration for languages in which there is
more than one allowed syntax for the same concept when appropriate,
and would see no problem in having both this syntax and a more compact
form.)

M

On Sat, Dec 24, 2011 at 09:27, David Wolfe <dav...@gm...> wrote:
> I'm still so used to juxtaposition to mean addition, that I'm somewhat
> averse to reclaiming juxtaposition for another use, even if it's not used
> for addition... unless additional syntactic sugar makes it yet more jarring
> such as:
>   (a){0|a}    or
>   _a{0|a}   (I like this better)
> Of course, perhaps those options are sufficiently jarring as to be
> disturbing.
>
> David
>
> On Fri, Dec 23, 2011 at 3:39 PM, Aaron Siegel <aar...@gm...>
> wrote:
>>
>> Just a heads up on some new features I've recently implemented and/or
>> thought about.  These are targeted for the 1.1 release.
>>
>> ORDINAL SUM.  The : operator now works as ordinal sum.  For example typing
>>
>> *:2
>>
>> gives the expected answer ^[2]*.  Ordinal sum even works for loopy games
>> (new to 1.1!), so for example, 1:off is over, and *:on is upon*.
>>
>> LOOPY GAMES.  The basic loopy games engine has been ported to 1.1.  You
>> can use "pass" for a pass move, e.g.,
>>
>> over := {0|pass};  upon := {pass|*};  etc.
>>
>> Decomposition into sides is automatic.  (Try over-over as an example)  I
>> find loopy games much easier to work with now than in 0.7.
>>
>> For longer loops, we need a way to indicate node labels.  Recall that in
>> 0.7, colon was used for this purpose; for example a:{0|a} was equal to
>> over.  This needs to change, since : is now reserved for ordinal sum.  One
>> idea would be to use a substitute a new symbol, such as @ or #, but I've
>> been toying around with simply juxtaposing the label, e.g.
>>
>> over := a{0|a};  upon := a{a|*};  etc.
>>
>> This works fine because in all other contexts, cgsuite expects an operator
>> to follow the identifier, so the immediate juxtaposition of an identifier
>> and a left-brace is unambiguous.  I'd welcome comments as to whether this
>> seems reasonable, or is just confusing.
>>
>> There are still some kinks but it seems to be converging nicely.
>>
>> LITERAL EXPRESSIONS.  You can enclose a braces-expression in single quotes
>> to denote a literal game expression.  This turns off simplification for the
>> immediate subexpression.  For example, typing
>>
>> '{0,1|}'
>>
>> will return the specific (option-closed) form '{0,1|}', without
>> simplifying to 2.  An immediate application is the Game.ExplicitForm
>> property, which was suggested by Neil awhile ago.  It expands (one level of)
>> the options of a game's canonical form.  For example,
>>
>> ^.Pow(2).ExplicitForm
>>
>> returns the answer
>>
>> '{0|v*}'
>>
>> This can be useful if cgsuite gives you an answer you don't understand.
>> For over.ExplicitForm (say), you'll get the answer
>>
>> '{0|over}'
>>
>> This works with ordinal sum provided the summands are loopfree.  It
>> doesn't work yet with loopy ordinal sums.  Once it does, then the definition
>> of G.PowTo can be simplified considerably, since if G = {0|H} then
>> G.PowTo(x) is always equal to
>>
>> '{|H}' : x.
>>
>> As an aside, the Game.ExplicitForm method is written in CGScript, and has
>> a particularly pleasing syntax:
>>
>> property ExplicitForm.get
>>     return '{ LeftOptions | RightOptions }';
>> end
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Write once. Port to many.
>> Get the SDK and tools to simplify cross-platform app development. Create
>> new or port existing apps to sell to consumers worldwide. Explore the
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> http://p.sf.net/sfu/intel-appdev
>> _______________________________________________
>> cgsuite-devel mailing list
>> cgs...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> cgsuite-devel mailing list
> cgs...@li...
> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>



-- 
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

Re: [cgsuite-devel] Some new features

[David W. <dav...@gm...>]

I'm still so used to juxtaposition to mean addition, that I'm somewhat
averse to reclaiming juxtaposition for another use, even if it's not used
for addition... unless additional syntactic sugar makes it yet more jarring
such as:
  (a){0|a}    or
  _a{0|a}   (I like this better)
Of course, perhaps those options are sufficiently jarring as to be
disturbing.

David

On Fri, Dec 23, 2011 at 3:39 PM, Aaron Siegel <aar...@gm...>wrote:

> Just a heads up on some new features I've recently implemented and/or
> thought about.  These are targeted for the 1.1 release.
>
> ORDINAL SUM.  The : operator now works as ordinal sum.  For example typing
>
> *:2
>
> gives the expected answer ^[2]*.  Ordinal sum even works for loopy games
> (new to 1.1!), so for example, 1:off is over, and *:on is upon*.
>
> LOOPY GAMES.  The basic loopy games engine has been ported to 1.1.  You
> can use "pass" for a pass move, e.g.,
>
> over := {0|pass};  upon := {pass|*};  etc.
>
> Decomposition into sides is automatic.  (Try over-over as an example)  I
> find loopy games much easier to work with now than in 0.7.
>
> For longer loops, we need a way to indicate node labels.  Recall that in
> 0.7, colon was used for this purpose; for example a:{0|a} was equal to
> over.  This needs to change, since : is now reserved for ordinal sum.  One
> idea would be to use a substitute a new symbol, such as @ or #, but I've
> been toying around with simply juxtaposing the label, e.g.
>
> over := a{0|a};  upon := a{a|*};  etc.
>
> This works fine because in all other contexts, cgsuite expects an operator
> to follow the identifier, so the immediate juxtaposition of an identifier
> and a left-brace is unambiguous.  I'd welcome comments as to whether this
> seems reasonable, or is just confusing.
>
> There are still some kinks but it seems to be converging nicely.
>
> LITERAL EXPRESSIONS.  You can enclose a braces-expression in single quotes
> to denote a literal game expression.  This turns off simplification for the
> immediate subexpression.  For example, typing
>
> '{0,1|}'
>
> will return the specific (option-closed) form '{0,1|}', without
> simplifying to 2.  An immediate application is the Game.ExplicitForm
> property, which was suggested by Neil awhile ago.  It expands (one level
> of) the options of a game's canonical form.  For example,
>
> ^.Pow(2).ExplicitForm
>
> returns the answer
>
> '{0|v*}'
>
> This can be useful if cgsuite gives you an answer you don't understand.
> For over.ExplicitForm (say), you'll get the answer
>
> '{0|over}'
>
> This works with ordinal sum provided the summands are loopfree.  It
> doesn't work yet with loopy ordinal sums.  Once it does, then the
> definition of G.PowTo can be simplified considerably, since if G = {0|H}
> then G.PowTo(x) is always equal to
>
> '{|H}' : x.
>
> As an aside, the Game.ExplicitForm method is written in CGScript, and has
> a particularly pleasing syntax:
>
> property ExplicitForm.get
>     return '{ LeftOptions | RightOptions }';
> end
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> cgsuite-devel mailing list
> cgs...@li...
> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>
>

[cgsuite-devel] Some new features

[Aaron S. <aar...@gm...>]

Just a heads up on some new features I've recently implemented and/or
thought about.  These are targeted for the 1.1 release.

ORDINAL SUM.  The : operator now works as ordinal sum.  For example typing

*:2

gives the expected answer ^[2]*.  Ordinal sum even works for loopy games
(new to 1.1!), so for example, 1:off is over, and *:on is upon*.

LOOPY GAMES.  The basic loopy games engine has been ported to 1.1.  You can
use "pass" for a pass move, e.g.,

over := {0|pass};  upon := {pass|*};  etc.

Decomposition into sides is automatic.  (Try over-over as an example)  I
find loopy games much easier to work with now than in 0.7.

For longer loops, we need a way to indicate node labels.  Recall that in
0.7, colon was used for this purpose; for example a:{0|a} was equal to
over.  This needs to change, since : is now reserved for ordinal sum.  One
idea would be to use a substitute a new symbol, such as @ or #, but I've
been toying around with simply juxtaposing the label, e.g.

over := a{0|a};  upon := a{a|*};  etc.

This works fine because in all other contexts, cgsuite expects an operator
to follow the identifier, so the immediate juxtaposition of an identifier
and a left-brace is unambiguous.  I'd welcome comments as to whether this
seems reasonable, or is just confusing.

There are still some kinks but it seems to be converging nicely.

LITERAL EXPRESSIONS.  You can enclose a braces-expression in single quotes
to denote a literal game expression.  This turns off simplification for the
immediate subexpression.  For example, typing

'{0,1|}'

will return the specific (option-closed) form '{0,1|}', without simplifying
to 2.  An immediate application is the Game.ExplicitForm property, which
was suggested by Neil awhile ago.  It expands (one level of) the options of
a game's canonical form.  For example,

^.Pow(2).ExplicitForm

returns the answer

'{0|v*}'

This can be useful if cgsuite gives you an answer you don't understand.
For over.ExplicitForm (say), you'll get the answer

'{0|over}'

This works with ordinal sum provided the summands are loopfree.  It doesn't
work yet with loopy ordinal sums.  Once it does, then the definition of
G.PowTo can be simplified considerably, since if G = {0|H} then G.PowTo(x)
is always equal to

'{|H}' : x.

As an aside, the Game.ExplicitForm method is written in CGScript, and has a
particularly pleasing syntax:

property ExplicitForm.get
    return '{ LeftOptions | RightOptions }';
end

Re: [cgsuite-devel] Pow in CanonicalShortGame

[Aaron S. <aar...@gm...>]

I've given this a bit of thought and I guess I've come around to the
conclusion that Neil is right, and the "correct" definition of ^.Pow(x) is
{0 | v[x-1]*} .  Here are my reasons (I'm using ^[x] and v[x] throughout
this discussion for ^.PowTo(x) and -^.PowTo(x), for clarity)

1. {0 | v[x-1]*} is a lot simpler than ^[x] - ^[x-1], canonically speaking.

2. The infinite generalizations make a lot more sense.  For example, it
seems natural to define

^.Pow(omega) = {0 | *, v*, v[2]*, v[3]*, ... }

Conversely, using the "other" definition, we could write ^.Pow(omega+1) =
^[omega+1] - ^[omega], but it's not clear what to do at limit ordinals.

3. Pseuduptimals.  This requires a bit more discussion, but it's worth it,
because to me it's the strongest of the three arguments, and it's
interesting on its own besides.

A stopper G is a pseudonumber if H^L < H^R for every follower H of G and
every H^L,H^R.  Note that this is exactly the same as the definition of
number, except we allow stoppers in addition to loopfree games.  It turns
out that the pseudonumbers are very natural loopy generalizations of
numbers.  Now the only *finite* pseudonumbers are on, off, dyadic
rationals, and games of the form x+over and x+under, where x is a dyadic
rational.

It turns out that if G is a pseudonumber, then we can define ^[G] = *:G - *
and ^.Pow(G+1) = {0 | v[G]*} and these "pseuduptimals" enjoy many of the
same properties as ordinary uptimals.  We're all familiar with ^[on]
("upon") and ^.Pow(on) ("uponth"), which are mentioned in Winning Ways and
elsewhere.  But we also have

^[over] ("upover") and ^.Pow(1+over) ("upoverth")

which have a lot of the same properties as upon and uponth, and behave just
like we'd expect, for example

upoverth << ^

while

^.Pow(1+x) << upoverth for all positive numbers x, and

upover has degree upoverth.

So far this doesn't bolster the case for {0 | v[x-1]*} because it turns out
that either definition gives us the same value for upoverth.  However
what's really swayed me is that upoverth is the natural limit of ^.Pow(1+x)
if we use Neil's definition.  We have

^ = {0|*}
^.Pow(3/2) = {0||0,v*|0,*}
^.Pow(5/4) = {0||0,{0,v*|0,*}|0,*}
^.Pow(9/8) = {0||0,{0,{0,v*|0,*}|0,*}|0,*}

...

upoverth = {0||0,pass|0,*}

So to summarize: the two definitions agree in the case of upoverth, so
there's no ambiguity there.  But Neil's definition gives us a sequence for
^.Pow(1+x) that converges naturally to the "unambiguous" upoverth, and the
other definition doesn't.  Seems pretty compelling.

I'll conclude by mentioning that the pseuduptimals seem like an absolutely
fascinating class of games... they seem to generalize the uptimals quite
nicely, and enjoy more regularity in some cases.  For example, a cursory
investigation suggests that the "two definitions" of ^.Pow(x) always agree
when x is a strictly loopy pseudouptimal.  For example, ^.Pow(5/4 + over) =
^[5/4 + over] - ^[1/4 + over].  This suggests that (in some sense) the
difference between the "two definitions" is a higher-order infinitesimal
that's absorbed by the loopiness of the pseuduptimal.  Neat.

On Sat, Dec 10, 2011 at 1:25 PM, Aaron Siegel <aar...@gm...>wrote:

> I read through the relevant section of ONaG again... my interpretation is
> that Conway only defines ^.Pow(x) when x is an integer, in which case the
> two definitions are equivalent.  So ONaG doesn't seem to advance an opinion
> on which generalization is "correct".  (Conway alludes to "up to the power
> of x" but never gives a definition for non-integer x... he only gives a
> definition for ^.PowTo(x), which is uncontroversial.)
>
> The reason I like CGSuite's definition is that it has the very "natural"
> closed form
>
> (*:x) - (*:(x-1))
>
> which strikes me as very appealing.  For x >= 2 this generalizes well to
> arbitrary G:
>
> (G:(x-1)) - (G:(x-2))
>
> which is consistent with [Moews 1996], although Moews, like Conway, only
> seems to consider the case where x is an integer.
>
> This being said, I agree with you that the literature on this subject is a
> bit thin, and you can tell by my comments in CGSuite that I'm somewhat
> agnostic.  Both generalizations have all the right properties (in terms of
> establishing the right order relations, etc).  I'd be very interested in
> any further insights ... have you written up the new results that support
> the case for {0 | G^R - G.PowTo(x-1)} ?  I'm intrigued.
>
> My reason for using ordinal sum rather than the recursive definition was
> purely for efficiency.  I can't now remember which cases I was trying to
> optimize... so you might be right that the "blowup" code can safely be
> replaced by the genetic form.  But I think it should be tested carefully so
> that we don't end up replacing the existing algorithm with something less
> efficient.
>
> -a
>
>
> On Wed, Dec 7, 2011 at 12:41 AM, Neil McKay <the...@gm...> wrote:
>
>> I'd like to change Pow. As this is a definition change resulting in
>> code change, I thought it should be discussed here.
>>
>> Currently, Pow is defined as follows:
>>
>>    method Pow(DyadicRational x)
>>
>>        if x < 1 then
>>            error("Exponent must be >= 1.");
>>        end
>>
>>        ro := RightOptions.AnyElement;
>>
>>        if ro === nil or this != {0|ro} then
>>            error("Base must be of the form {0|H}.");
>>        end
>>
>>        if x is Integer then
>>            // This is equal to PowTo(x) - PowTo(x-1) in the case of
>> an integer and is much faster
>>            // to calculate.  Perhaps it's the right definition even
>> in the non-integer case.
>>            // Still a bit of unresolved theory.
>>            return { 0 | ro - PowTo(x-1) };
>>        else
>>            return PowTo(x) - PowTo(x-1);
>>        end
>>
>>    end
>>
>> The reasoning for the current situation is given in the comments, but
>> I'm not convinced. I think if anything, Conway (ONAG, p. 195) gives
>> the option based definition as the default and the partial sum based
>> definition for the integer case. Also, work I've done suggests this is
>> a better definition, but I might seem like a biased source in this
>> email. Lastly, I can't find examples of these definition used for
>> non-integers outside of my work; if anyone knows of any, I'd be happy
>> to see it.
>>
>> I propose the code be changed to:
>>
>>    method Pow(DyadicRational x)
>>
>>        if x < 1 then
>>            error("Exponent must be >= 1.");
>>        end
>>
>>        if LeftOptions.Size != 1 or LeftOptions.AnyElement != 0 or
>> RightOptions.Size != 1 then
>>            error("Base must be of the form {0|H}.");
>>        end
>>
>>        return { 0 | RightOptions.AnyElement - PowTo(x-1) };
>>    end
>>
>> If the error part of my suggestion is worse than the original, then
>> I'm happy to only change the other part, but I'd like someone to
>> educate me on why it is worse.
>>
>> Also, I think:
>>
>>        return
>> {PowTo(x.LeftOptions.AnyElement)|*,PowTo(x.RightOptions.AnyElement)};
>>
>> can replace:
>>
>>        if x >= 1 then
>>            // As given by [Moews 1996].
>>            return OrdinalSum(x-1);
>>        else
>>            /* This case is interesting and surprising.  It's equal to
>> OrdinalSum(y), where y is the
>>               "blowup" of x-1, obtained by removing Left's moves to
>> -1 from the canonical form of x-1.
>>               For example, if x == 3/8, then
>>
>>               x-1 == -5/8 == {-3/4|-1/2} == { {-1||-1|0} ||| {-1|0} }
>>
>>               so Blowup(x-1) == { {.||.|0} ||| {.|0} } == { -2 | -1 }
>> = -3/2.  Sure enough,
>>
>>               ^.OrdinalSum(-3/2) == ^.PowTo(3/8) == *.OrdinalSum(3/8) + *
>>
>>               agreeing with the other definitions of ^.PowTo(3/8). */
>>
>>            return OrdinalSum(CanonicalShortGame.Blowup(x-1));
>>        end
>>
>> in PowTo, or at least the Blowup part if OrdinalSum is more efficient
>> for the other part. This change is just a suggested code change, not a
>> definition change.
>>
>>
>> ------------------------------------------------------------------------------
>> Cloud Services Checklist: Pricing and Packaging Optimization
>> This white paper is intended to serve as a reference, checklist and point
>> of
>> discussion for anyone considering optimizing the pricing and packaging
>> model
>> of a cloud services business. Read Now!
>> http://www.accelacomm.com/jaw/sfnl/114/51491232/
>> _______________________________________________
>> cgsuite-devel mailing list
>> cgs...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>>
>
>

Re: [cgsuite-devel] Bug or feature regarding .Tiny?

[Aaron S. <aar...@gm...>]

(-2).Tiny is the game

{0||0|+2}

which is, indeed, 1/2.  (This is "tiny negative 2" which isn't really a
tiny at all.  Perhaps I should be raising an error here, rather than
returning the "correct" answer of 1/2?)

In any case the minus sign certainly shouldn't be expected to commute with
.Tiny

On Mon, Dec 12, 2011 at 10:01 AM, Martin Mueller <mmu...@ua...>wrote:

> This is with CGSuite 1.0 on a Mac.
>
> -2.Tiny yields -(subscript)2, as expected (?), but
> (-2).Tiny yields 1/2.
>
> I had trouble finding the documentation for the .Tiny method, but this
> (with braces) is what my student used in her assignment...
>
>        Martin
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> cgsuite-devel mailing list
> cgs...@li...
> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>

[cgsuite-devel] Bug or feature regarding .Tiny?

[Martin M. <mmu...@ua...>]

This is with CGSuite 1.0 on a Mac.

-2.Tiny yields -(subscript)2, as expected (?), but
(-2).Tiny yields 1/2.

I had trouble finding the documentation for the .Tiny method, but this (with braces) is what my student used in her assignment...

	Martin

Re: [cgsuite-devel] Pow in CanonicalShortGame

[Aaron S. <aar...@gm...>]

I read through the relevant section of ONaG again... my interpretation is
that Conway only defines ^.Pow(x) when x is an integer, in which case the
two definitions are equivalent.  So ONaG doesn't seem to advance an opinion
on which generalization is "correct".  (Conway alludes to "up to the power
of x" but never gives a definition for non-integer x... he only gives a
definition for ^.PowTo(x), which is uncontroversial.)

The reason I like CGSuite's definition is that it has the very "natural"
closed form

(*:x) - (*:(x-1))

which strikes me as very appealing.  For x >= 2 this generalizes well to
arbitrary G:

(G:(x-1)) - (G:(x-2))

which is consistent with [Moews 1996], although Moews, like Conway, only
seems to consider the case where x is an integer.

This being said, I agree with you that the literature on this subject is a
bit thin, and you can tell by my comments in CGSuite that I'm somewhat
agnostic.  Both generalizations have all the right properties (in terms of
establishing the right order relations, etc).  I'd be very interested in
any further insights ... have you written up the new results that support
the case for {0 | G^R - G.PowTo(x-1)} ?  I'm intrigued.

My reason for using ordinal sum rather than the recursive definition was
purely for efficiency.  I can't now remember which cases I was trying to
optimize... so you might be right that the "blowup" code can safely be
replaced by the genetic form.  But I think it should be tested carefully so
that we don't end up replacing the existing algorithm with something less
efficient.

-a

On Wed, Dec 7, 2011 at 12:41 AM, Neil McKay <the...@gm...> wrote:

> I'd like to change Pow. As this is a definition change resulting in
> code change, I thought it should be discussed here.
>
> Currently, Pow is defined as follows:
>
>    method Pow(DyadicRational x)
>
>        if x < 1 then
>            error("Exponent must be >= 1.");
>        end
>
>        ro := RightOptions.AnyElement;
>
>        if ro === nil or this != {0|ro} then
>            error("Base must be of the form {0|H}.");
>        end
>
>        if x is Integer then
>            // This is equal to PowTo(x) - PowTo(x-1) in the case of
> an integer and is much faster
>            // to calculate.  Perhaps it's the right definition even
> in the non-integer case.
>            // Still a bit of unresolved theory.
>            return { 0 | ro - PowTo(x-1) };
>        else
>            return PowTo(x) - PowTo(x-1);
>        end
>
>    end
>
> The reasoning for the current situation is given in the comments, but
> I'm not convinced. I think if anything, Conway (ONAG, p. 195) gives
> the option based definition as the default and the partial sum based
> definition for the integer case. Also, work I've done suggests this is
> a better definition, but I might seem like a biased source in this
> email. Lastly, I can't find examples of these definition used for
> non-integers outside of my work; if anyone knows of any, I'd be happy
> to see it.
>
> I propose the code be changed to:
>
>    method Pow(DyadicRational x)
>
>        if x < 1 then
>            error("Exponent must be >= 1.");
>        end
>
>        if LeftOptions.Size != 1 or LeftOptions.AnyElement != 0 or
> RightOptions.Size != 1 then
>            error("Base must be of the form {0|H}.");
>        end
>
>        return { 0 | RightOptions.AnyElement - PowTo(x-1) };
>    end
>
> If the error part of my suggestion is worse than the original, then
> I'm happy to only change the other part, but I'd like someone to
> educate me on why it is worse.
>
> Also, I think:
>
>        return
> {PowTo(x.LeftOptions.AnyElement)|*,PowTo(x.RightOptions.AnyElement)};
>
> can replace:
>
>        if x >= 1 then
>            // As given by [Moews 1996].
>            return OrdinalSum(x-1);
>        else
>            /* This case is interesting and surprising.  It's equal to
> OrdinalSum(y), where y is the
>               "blowup" of x-1, obtained by removing Left's moves to
> -1 from the canonical form of x-1.
>               For example, if x == 3/8, then
>
>               x-1 == -5/8 == {-3/4|-1/2} == { {-1||-1|0} ||| {-1|0} }
>
>               so Blowup(x-1) == { {.||.|0} ||| {.|0} } == { -2 | -1 }
> = -3/2.  Sure enough,
>
>               ^.OrdinalSum(-3/2) == ^.PowTo(3/8) == *.OrdinalSum(3/8) + *
>
>               agreeing with the other definitions of ^.PowTo(3/8). */
>
>            return OrdinalSum(CanonicalShortGame.Blowup(x-1));
>        end
>
> in PowTo, or at least the Blowup part if OrdinalSum is more efficient
> for the other part. This change is just a suggested code change, not a
> definition change.
>
>
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point
> of
> discussion for anyone considering optimizing the pricing and packaging
> model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> cgsuite-devel mailing list
> cgs...@li...
> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>

[cgsuite-devel] Pow in CanonicalShortGame

[Neil M. <the...@gm...>]

I'd like to change Pow. As this is a definition change resulting in
code change, I thought it should be discussed here.

Currently, Pow is defined as follows:

    method Pow(DyadicRational x)

        if x < 1 then
            error("Exponent must be >= 1.");
        end

        ro := RightOptions.AnyElement;

        if ro === nil or this != {0|ro} then
            error("Base must be of the form {0|H}.");
        end

        if x is Integer then
            // This is equal to PowTo(x) - PowTo(x-1) in the case of
an integer and is much faster
            // to calculate.  Perhaps it's the right definition even
in the non-integer case.
            // Still a bit of unresolved theory.
            return { 0 | ro - PowTo(x-1) };
        else
            return PowTo(x) - PowTo(x-1);
        end

    end

The reasoning for the current situation is given in the comments, but
I'm not convinced. I think if anything, Conway (ONAG, p. 195) gives
the option based definition as the default and the partial sum based
definition for the integer case. Also, work I've done suggests this is
a better definition, but I might seem like a biased source in this
email. Lastly, I can't find examples of these definition used for
non-integers outside of my work; if anyone knows of any, I'd be happy
to see it.

I propose the code be changed to:

    method Pow(DyadicRational x)

        if x < 1 then
            error("Exponent must be >= 1.");
        end

        if LeftOptions.Size != 1 or LeftOptions.AnyElement != 0 or
RightOptions.Size != 1 then
            error("Base must be of the form {0|H}.");
        end

        return { 0 | RightOptions.AnyElement - PowTo(x-1) };
    end

If the error part of my suggestion is worse than the original, then
I'm happy to only change the other part, but I'd like someone to
educate me on why it is worse.

Also, I think:

        return {PowTo(x.LeftOptions.AnyElement)|*,PowTo(x.RightOptions.AnyElement)};

can replace:

        if x >= 1 then
            // As given by [Moews 1996].
            return OrdinalSum(x-1);
        else
            /* This case is interesting and surprising.  It's equal to
OrdinalSum(y), where y is the
               "blowup" of x-1, obtained by removing Left's moves to
-1 from the canonical form of x-1.
               For example, if x == 3/8, then

               x-1 == -5/8 == {-3/4|-1/2} == { {-1||-1|0} ||| {-1|0} }

               so Blowup(x-1) == { {.||.|0} ||| {.|0} } == { -2 | -1 }
= -3/2.  Sure enough,

               ^.OrdinalSum(-3/2) == ^.PowTo(3/8) == *.OrdinalSum(3/8) + *

               agreeing with the other definitions of ^.PowTo(3/8). */

            return OrdinalSum(CanonicalShortGame.Blowup(x-1));
        end

in PowTo, or at least the Blowup part if OrdinalSum is more efficient
for the other part. This change is just a suggested code change, not a
definition change.

Re: [cgsuite-devel] CGSuite 1.0

[Neil M. <the...@gm...>]

Hi Aaron,

I have some comments about installation on GNU/Linux.

I first tried to install as non-root, and during the install it was
noted that /home/nmckay/CGSuite was not empty. I deleted it and moved
on. Everything proceeded as normal, but when I ran CGSuite it couldn't
find startup.cgs (in fact, I think CGSuite installed itself in
/home/nmckay/CGSuite).

Next I installed on another machine, but first removing
/home/nmckay/CGSuite. I installed as root, and the install went fine,
but I had trouble after running the program as non-root, because there
was trouble accessing /home/nmckay/.CGSuite/dev
I removed the directory .CGSuite and then it loaded fine, and continues to.

I just installed as root on a machine that has not had CGSuite 1.0
installed, and everything worked fine with the installer launching the
program the first time.

Summary: I had trouble, but I think it was all related to my NetBeans
version having been installed already. Also, the uninstaller works
fine.

Neil

On Fri, Dec 2, 2011 at 7:49 PM, Aaron Siegel <aar...@gm...> wrote:
> I just released CGSuite 1.0 !  You can download a copy at
>
> http://www.cgsuite.org/
>
> I strongly recommend installing a copy from the standard distribution of
> CGSuite for "everyday" (non-development) use.  The distributions provide
> much better integration with the operating system (you don't have to go
> through NetBeans to run CGSuite, etc.)
>
> If you experience any problems with the installation, please let me know...
> thanks!
>
> ------------------------------------------------------------------------------
> 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. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> cgsuite-devel mailing list
> cgs...@li...
> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>

[cgsuite-devel] CGSuite 1.0

[Aaron S. <aar...@gm...>]

I just released CGSuite 1.0 !  You can download a copy at

http://www.cgsuite.org/

I strongly recommend installing a copy from the standard distribution of
CGSuite for "everyday" (non-development) use.  The distributions provide
much better integration with the operating system (you don't have to go
through NetBeans to run CGSuite, etc.)

If you experience any problems with the installation, please let me know...
thanks!

[cgsuite-devel] Package lookup issue

[Aaron S. <aar...@gm...>]

Neil recently identified a potential source of confusion with the way
CGSuite does package lookups.

Suppose we have a class MyClass with a member variable called "heap".  It
contains something like the following bit of code:

     return heap.NimValue;

to access the NimValue property of the heap object.

Now suppose the user goes and creates a directory in his User Folder called
"heap".  This is a perfectly reasonable thing to do (the user might want to
store his own customized heap game implementations there, for example).
The user hasn't made any changes to MyClass, but now when he calls the
above code the answer will be "Class not found: heap.NimValue" ... because
now "heap" is the name of a package, and CGSuite is interpreting
"heap.NimValue" to mean "give me the class NimValue from the package
heap."  Effectively, by creating the "heap" directory, the user has broken
every class that has a member variable called "heap".  If MyClass happens
to be in the System Folder, then the user has broken the core CGSuite
library.

This is obviously undesirable - the user shouldn't be able to break the
core library by setting up a namespace conflict in his User Folder.

Proposed solution: prohibit qualified references to class names from inside
a class.  That is, expressions like

     game.grid.Amazons

would be legal *only* on the Worksheet, and *not* within a class.  To do
this within a class, you'd need to use an import such as

     import game.grid.Amazons;

at the top of the file.

I'm planning to go ahead and implement this (it's an easy change) but I
thought I'd submit it for comment first.  I made the change locally and all
400+ unit tests passed - which tells us that none of the code in the
library actually uses this type of reference, so presumably it won't be
missed.

Re: [cgsuite-devel] 1.0 release forthcoming

[<rj...@ma...>]

Aaron,

I've been too busy lately to give any good (or bad) suggestions. I look
forward to the
release.

Richard

> Thanks for the detailed suggestions!  For 1.0 I want to keep the focus on
> bugfixes, but these are worth considering for v 1.1 (which we can get
> started on as soon as 1.0 is released)
>
> There's a Direction.All variable that's statically equal to the set of all
> Direction values.  Perhaps this should just be generalized to an arbitrary
> enum, so that every enum class has an All variable.  Then Player.All would
> be defined as {Player.Left, Player.Right} and so on.
>
> The new methods for Table/List/Set are no-brainers.  Likewise to all of
> the
> succeeding suggestions except possibly the last two... I personally prefer
> that 1*2 be displayed as "1*2" but perhaps "1+*2" would be clearer and
> more
> consistent.  I see the merits of "andfor" or something similar, but it's a
> bit controversial as I'm not aware of any other scripting language with a
> keyword like that.  I'd favor giving these a bit more thought, and
> implementing the others in version 1.1.
>
> On Thu, Nov 17, 2011 at 5:52 AM, Neil McKay <the...@gm...> wrote:
>
>> Hi all,
>>
>> I don't know if the last minute lasts for 5 days, but I have complied
>> a few more thoughts I've had for cgsuite.
>>
>> Sometimes instead of
>> for p in {Player.Left, Player.Right} do
>> I'd like to loop over all parts of an enum type without listing what
>> they
>> are
>>
>> tables are very useful, but still not as easy to work with as I'd
>> like; perhaps some of these methods would make them better.
>> Table
>> .AddRow
>> .AddColumn
>> .Size
>> .Transpose
>> .Flatten
>> .Elements
>> .Rows
>> .Columns
>> .Contains
>>
>> these are things I like to do that could be methods:
>> List/Set
>> .PartialSums
>> .Differences
>>
>> Explorer
>> - expand all options, all followers (I want to be able to expand the
>> whole game tree)
>>
>> Worksheet.Print
>> - option to print collection items one per line
>> - option to only print first x lines or characters
>>
>> pressing "up-arrow" to go through previous commands, should go to top
>> of previous commands so that it is easier to go faster and easier to
>> keep track of how many times you have to press up to go back to the
>> 3rd last command
>>
>> Non-canonical bases for OrdinalSum (maybe this is doable now, I don't
>> see how to get cgsuite to do it though)
>>
>> Collapsed error messages (when I run an unending call and cgsuite
>> stops I'd rather have the many lines of errors collapsed as I have no
>> way to remove any output without restarting)
>>
>> Sometimes I want the following information of a game
>> .Followers
>> .IsFollower(g)
>>
>> I think .Incentives should work like .Options, that is,
>> .Incentives(Player.Left) instead of a pile of incentives with
>> dominated options removed
>>
>> I want 1+*2 to display as 1+*2 instead of 1*2 which returns 2 when
>> copied and pasted
>>
>> andfor (the for analog of elseif) would be nice; I often have nested
>> for-loops that all end at the same spot, this would save tabbing,
>> repeated end statements and at times clarify the commutativity of my
>> for statements.
>>
>> Neil
>>
>> On Fri, Nov 11, 2011 at 6:28 PM, Aaron Siegel <aar...@gm...>
>> wrote:
>> > Hi
>> >
>> > I'm planning to release version 1.0 very soon.  I think it's
>> reasonably
>> > stable.  I've decided not to introduce : for ordinal sum in 1.0, but
>> to
>> > defer this for the 1.1 release (along with several other features).  I
>> did
>> > refactor iterators -> iterator as we discussed.
>> >
>> > I'd welcome any last-minute comments or suggestions (for tweaking the
>> > interface, scripting language, documentation, etc.)
>> >
>> > Thanks to everyone who helped out with this release!  I'm looking
>> forward to
>> > it...
>> >
>> > -a
>> >
>> >
>> ------------------------------------------------------------------------------
>> > RSA(R) Conference 2012
>> > Save $700 by Nov 18
>> > Register now
>> > http://p.sf.net/sfu/rsa-sfdev2dev1
>> > _______________________________________________
>> > cgsuite-devel mailing list
>> > cgs...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>> >
>> >
>>
> ------------------------------------------------------------------------------
> 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. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
> cgsuite-devel mailing list
> cgs...@li...
> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>


-- 
Richard Nowakowski
Dept. Mathematics & Statistics
PO BOX 15000
Halifax, NS  B3H 4R2

Phone (902)-494-6635
FAX (902)-494-5130

Re: [cgsuite-devel] 1.0 release forthcoming

[Aaron S. <aar...@gm...>]

Thanks for the detailed suggestions!  For 1.0 I want to keep the focus on
bugfixes, but these are worth considering for v 1.1 (which we can get
started on as soon as 1.0 is released)

There's a Direction.All variable that's statically equal to the set of all
Direction values.  Perhaps this should just be generalized to an arbitrary
enum, so that every enum class has an All variable.  Then Player.All would
be defined as {Player.Left, Player.Right} and so on.

The new methods for Table/List/Set are no-brainers.  Likewise to all of the
succeeding suggestions except possibly the last two... I personally prefer
that 1*2 be displayed as "1*2" but perhaps "1+*2" would be clearer and more
consistent.  I see the merits of "andfor" or something similar, but it's a
bit controversial as I'm not aware of any other scripting language with a
keyword like that.  I'd favor giving these a bit more thought, and
implementing the others in version 1.1.

On Thu, Nov 17, 2011 at 5:52 AM, Neil McKay <the...@gm...> wrote:

> Hi all,
>
> I don't know if the last minute lasts for 5 days, but I have complied
> a few more thoughts I've had for cgsuite.
>
> Sometimes instead of
> for p in {Player.Left, Player.Right} do
> I'd like to loop over all parts of an enum type without listing what they
> are
>
> tables are very useful, but still not as easy to work with as I'd
> like; perhaps some of these methods would make them better.
> Table
> .AddRow
> .AddColumn
> .Size
> .Transpose
> .Flatten
> .Elements
> .Rows
> .Columns
> .Contains
>
> these are things I like to do that could be methods:
> List/Set
> .PartialSums
> .Differences
>
> Explorer
> - expand all options, all followers (I want to be able to expand the
> whole game tree)
>
> Worksheet.Print
> - option to print collection items one per line
> - option to only print first x lines or characters
>
> pressing "up-arrow" to go through previous commands, should go to top
> of previous commands so that it is easier to go faster and easier to
> keep track of how many times you have to press up to go back to the
> 3rd last command
>
> Non-canonical bases for OrdinalSum (maybe this is doable now, I don't
> see how to get cgsuite to do it though)
>
> Collapsed error messages (when I run an unending call and cgsuite
> stops I'd rather have the many lines of errors collapsed as I have no
> way to remove any output without restarting)
>
> Sometimes I want the following information of a game
> .Followers
> .IsFollower(g)
>
> I think .Incentives should work like .Options, that is,
> .Incentives(Player.Left) instead of a pile of incentives with
> dominated options removed
>
> I want 1+*2 to display as 1+*2 instead of 1*2 which returns 2 when
> copied and pasted
>
> andfor (the for analog of elseif) would be nice; I often have nested
> for-loops that all end at the same spot, this would save tabbing,
> repeated end statements and at times clarify the commutativity of my
> for statements.
>
> Neil
>
> On Fri, Nov 11, 2011 at 6:28 PM, Aaron Siegel <aar...@gm...>
> wrote:
> > Hi
> >
> > I'm planning to release version 1.0 very soon.  I think it's reasonably
> > stable.  I've decided not to introduce : for ordinal sum in 1.0, but to
> > defer this for the 1.1 release (along with several other features).  I
> did
> > refactor iterators -> iterator as we discussed.
> >
> > I'd welcome any last-minute comments or suggestions (for tweaking the
> > interface, scripting language, documentation, etc.)
> >
> > Thanks to everyone who helped out with this release!  I'm looking
> forward to
> > it...
> >
> > -a
> >
> >
> ------------------------------------------------------------------------------
> > RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > _______________________________________________
> > cgsuite-devel mailing list
> > cgs...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
> >
> >
>

Re: [cgsuite-devel] 1.0 release forthcoming

[Neil M. <the...@gm...>]

Hi all,

I don't know if the last minute lasts for 5 days, but I have complied
a few more thoughts I've had for cgsuite.

Sometimes instead of
for p in {Player.Left, Player.Right} do
I'd like to loop over all parts of an enum type without listing what they are

tables are very useful, but still not as easy to work with as I'd
like; perhaps some of these methods would make them better.
Table
.AddRow
.AddColumn
.Size
.Transpose
.Flatten
.Elements
.Rows
.Columns
.Contains

these are things I like to do that could be methods:
List/Set
.PartialSums
.Differences

Explorer
- expand all options, all followers (I want to be able to expand the
whole game tree)

Worksheet.Print
- option to print collection items one per line
- option to only print first x lines or characters

pressing "up-arrow" to go through previous commands, should go to top
of previous commands so that it is easier to go faster and easier to
keep track of how many times you have to press up to go back to the
3rd last command

Non-canonical bases for OrdinalSum (maybe this is doable now, I don't
see how to get cgsuite to do it though)

Collapsed error messages (when I run an unending call and cgsuite
stops I'd rather have the many lines of errors collapsed as I have no
way to remove any output without restarting)

Sometimes I want the following information of a game
.Followers
.IsFollower(g)

I think .Incentives should work like .Options, that is,
.Incentives(Player.Left) instead of a pile of incentives with
dominated options removed

I want 1+*2 to display as 1+*2 instead of 1*2 which returns 2 when
copied and pasted

andfor (the for analog of elseif) would be nice; I often have nested
for-loops that all end at the same spot, this would save tabbing,
repeated end statements and at times clarify the commutativity of my
for statements.

Neil

On Fri, Nov 11, 2011 at 6:28 PM, Aaron Siegel <aar...@gm...> wrote:
> Hi
>
> I'm planning to release version 1.0 very soon.  I think it's reasonably
> stable.  I've decided not to introduce : for ordinal sum in 1.0, but to
> defer this for the 1.1 release (along with several other features).  I did
> refactor iterators -> iterator as we discussed.
>
> I'd welcome any last-minute comments or suggestions (for tweaking the
> interface, scripting language, documentation, etc.)
>
> Thanks to everyone who helped out with this release!  I'm looking forward to
> it...
>
> -a
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> cgsuite-devel mailing list
> cgs...@li...
> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>
>

[cgsuite-devel] 1.0 release forthcoming

[Aaron S. <aar...@gm...>]

Hi

I'm planning to release version 1.0 very soon.  I think it's reasonably
stable.  I've decided not to introduce : for ordinal sum in 1.0, but to
defer this for the 1.1 release (along with several other features).  I did
refactor iterators -> iterator as we discussed.

I'd welcome any last-minute comments or suggestions (for tweaking the
interface, scripting language, documentation, etc.)

Thanks to everyone who helped out with this release!  I'm looking forward
to it...

-a

Re: [cgsuite-devel] Ordinal Sum

[<rj...@ma...>]

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

Re: [cgsuite-devel] Ordinal Sum

[Neil M. <the...@gm...>]

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 <aar...@gm...> 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 well-established 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 built-in 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 1-point ko
>
> a:{1|a||0}
>
> can't be entered using "pass".
>
> On Tue, Oct 11, 2011 at 7:10 PM, Neil McKay <the...@gm...> 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 <ma...@cs...>
>> 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/splunk-d2d-oct
>> > _______________________________________________
>> > cgsuite-devel mailing list
>> > cgs...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>> >
>
>

Re: [cgsuite-devel] Ordinal Sum

[Aaron S. <aar...@gm...>]

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 well-established 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 built-in 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 1-point ko

a:{1|a||0}

can't be entered using "pass".

On Tue, Oct 11, 2011 at 7:10 PM, Neil McKay <the...@gm...> 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 <ma...@cs...>
> 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/splunk-d2d-oct
> > _______________________________________________
> > cgsuite-devel mailing list
> > cgs...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
> >
>

Re: [cgsuite-devel] Ordinal Sum

[Neil M. <the...@gm...>]

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 <ma...@cs...> 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/splunk-d2d-oct
> _______________________________________________
> cgsuite-devel mailing list
> cgs...@li...
> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>

Re: [cgsuite-devel] Ordinal Sum

[Michael A. <ma...@cs...>]

>
> 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

Re: [cgsuite-devel] Ordinal Sum

[David W. <dav...@gm...>]

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 <aar...@gm...>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 1-1:^ 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/splunk-d2d-oct
> _______________________________________________
> cgsuite-devel mailing list
> cgs...@li...
> https://lists.sourceforge.net/lists/listinfo/cgsuite-devel
>
>