rails-devel — List for discussion of Rails development

Re: [Rails-devel] Current implementation, branch Rails 2.0?

[Erik V. <eri...@xs...>]

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> As I proposed before, I can reorganize OperatingRound to group the
> methods by function (OR step), each with some descriptive header.
> That's all I can do on short term. It might make OR easier to read, and
> perhaps it could be a starter for later refactoring.

Done.

Re: [Rails-devel] Current implementation, branch Rails 2.0?

[Stefan F. <ste...@we...>]

> All fine, but so what?  Is size bad per se?
> 

Erik,
No certainly not. All this is not about good or bad. In one sense the size 
shows the thoughts and efforts for all details you have put into those 
classes.

It is the other way around: As I do not have the time and the memory to 
understand all thoughts and conditions you considered, that created that code, 
I would prefer to digest all that in little portions. 

Organizing code into classes allows to review only the relevant classes that 
you need know. It is like organizing stuff into little boxes where you put 
labels on the boxes what is inside. This makes it much easier to find things 
and to understand the big picture: Maybe like in a big department store: It is 
much easier to get an overview by studying the directory of the store instead 
of searching every shelf.

An object orientated languages allows storing pieces of code in classes and if 
I want rewrite/change/add something to a class, I have to make sure that after 
my changes everything works as before. If the class is small, it is easier to 
check if I do not introduce side effects and I only have to test the part 
where the class is responsible for: So take the example for the 
OperatingRound. If I change anything inside I have to test all functionality 
which is managed by the OperatingRound. Thus I change something related to 
token lay, it can potentially have side effects on tile laying, revenue 
payouts, train buying, loans etc. 

If the token lay code is inside in a separate class it is impossible to effect 
the other functionality of OperatingRound. 

I had the issue more than a year ago: I started adding the NoMap 
functionalities which in principle should only change Tile and Token Lay. 
However due to side effects of my (at that time bad understanding) of the step 
mechanism inside the OperatingRound I broke the 1856 loan mechanism.
And I was not even aware of that code as this code was part of a subclass of 
OperatingRound.

The same issue about the size of classes effects writing unit tests: For 
refactoring the best is to have the class covered fully by unit tests. If you 
have two small classes instead of one large you can start refactoring earlier 
than you had to write all tests first.

And the other good thing is, that with smaller classes it is less likely that 
two people work at the same time on the same class, thus it makes merging and 
potential merge conflicts less likely.

For my daily job I have to deal with large programs in non-object orientated 
languages and even there I prefer to split problems into smaller, independent 
pieces. Especially if you come back to those programs several years later, it 
makes it much easier to enhance or fix something. 

OK enough text, but it is not about fashionable or good/bad, it is simply
about making coding easier and so increase the fun part of it.

Stefan

´

Re: [Rails-devel] Current implementation, branch Rails 2.0?

[brett l. <bre...@gm...>]

On Thu, Aug 11, 2011 at 1:02 PM, Erik Vos <eri...@xs...> wrote:
>> See below for some stats if you do not believe my words.
>
> All fine, but so what?  Is size bad per se?

Class size is a leading indicator of excessive complexity, conflicting
goals, unclear design, or just generally difficult to understand code.
It's not a hard and fast rule, but it's usually an indicator of
"smelly code". [1] [2]

In general, a class should have a single, clearly defined
responsibility. I think the Hex, MapHex, GUIHex classes do a pretty
decent job of staying within their defined sets of responsibilities.
It's not perfect, but I think it illustrates the point. Also, I'm not
saying that there is a set line count limit for all classes. For
example, much of the GUI classes are going to be somewhat lengthy just
by virtue of how AWT/Swing is designed.

We're just getting to the point in the lifecycle of the project where
some of our old design decisions need to be revisited. There's a few
of those old decisions that, if we're going to be able to continue
moving the project forward, are going to need to be re-decided in
light of where we're at now.

---Brett.

[1] http://www.codinghorror.com/blog/2006/05/code-smells.html
[2] http://www.ibm.com/developerworks/java/library/j-cq06306/index.html

Re: [Rails-devel] Current implementation, branch Rails 2.0?

[Erik V. <eri...@xs...>]

See below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]

> In my understanding of Rails the term action is something different: All
of
> them are user's actions and extend  the abstract class PossibleAction and
> belong to the rails.game.action package.
> 
> This new kind of "action" is in my eyes a named trigger which is activated
by
> the train purchase. 

By the phase change, to be precise.  Indeed the term "action" is a bit
confusing.

> There is no need to pass the trigger through
> GameManager and Round classes with new methods and then call from the
> OperatingRound the method inside PublicCompany_TN.
> 
> My preferred solution would have been the possibility for
> PublicCompany_TN to register themselves with the PhaseManager and then
> get updated directly.

That's indeed another possible approach.  I'll consider it.
It's probably more fashionable. 

> And only by convention actions are passed from GameManager to the Round
> (sub-)classes , but they design neither encourages nor enforces this:
> Take for example the correction actions, they are processed in individual
> manager classes, and there is one for each action. 

I'm not sure if that doesn't amount to multiplying entities beyond
necessity.

> If I have taken your
> approach all code inside the correction package would have been added to
> the GameManager too.
> And that is my proposal or roadmap for those classes: Try to get
> GameManager focused on what is required for the top level class of the
> game (thus mainly storing the other component managers and interacting
> between them). Clean up the Rounds to include only the mechanisms to
> proceed from activity/step to the next and to switch between
> players/companies. All action processing should be done outside in
individual
> components/classes.
> 
> For you it might seem easier to have everything in one place/file, but  I
would
> prefer to refactor it somehow, before I am able to implement required
> adjustments for other games.
> 
> Similar as it is difficult for you to write revenue code, it is difficult
for others to
> change the Round or GameManager classes. But if nearly everything
> important is inside those classes, no one else will be able to help you
> implement the parts of new games that require changing those classes.
> 
> But if you split those classes into smaller pieces it makes it easier for
> outsiders (including myself) to understand the insides and it is less
risky to
> change it without causing side effects.

As I proposed before, I can reorganize OperatingRound to group the methods
by function (OR step), each with some descriptive header.
That's all I can do on short term. It might make OR easier to read, and
perhaps it could be a starter for later refactoring.

> See below for some stats if you do not believe my words.

All fine, but so what?  Is size bad per se?  

> However as I seem it hardly possible to refactor against a moving target
(as
> you are stilling adding new functions to the core classes - and rightly do
so, as
> long as there is no alternative), I suggest to create a new branch inside
the git
> repo for a potential Rails 2.0.

Large-scale refactoring of Rails should certainly be done in a separate
branch.

Erik.

Re: [Rails-devel] Automated test reports without currency identifier (19de64)

[John A. T. <ja...@ja...>]

On Thu, Aug 11, 2011 at 12:25 PM, Stefan Frey <ste...@we...> wrote:

> no, it does not. So either we have to make sure that UTF-8 is working
> everywhere (git-repo and all developers clones) or pipe the report output
> at the test run through a conversion to an ISO-8859-1 charset as in HTML.


There is no guarantee that every character is representable in Latin1.
Time to stop living in the 80s and just use Unicode.

-- 
John A. Tamplin

Re: [Rails-devel] Current implementation, branch Rails 2.0?

[brett l. <bre...@gm...>]

On Thu, Aug 11, 2011 at 10:09 AM, Stefan Frey <ste...@we...> wrote:
> On Wednesday, August 10, 2011 12:31:42 pm Erik Vos wrote:
> However as I seem it hardly possible to refactor against a moving target (as
> you are stilling adding new functions to the core classes - and rightly do so,
> as long as there is no alternative), I suggest to create a new branch inside
> the git repo for a potential Rails 2.0.
>
> This branch would allow to refactor main parts without any fear to break the
> existing code/games/save files etc. It would also allow cleaning up from
> legacy code and components and a better support for unit testing.
>
> In the main trunk new games/features could still be added to Rails 1.x, until
> Rails 2.0 is stable/mature enough.
>
> Stefan


I'm open to this. It sounds like public topic branches may be
necessary for publishing larger chunks of work prior to being merged
into master. It may also help us discuss more extensive changes, if we
can pull down a published branch to review the changes. Sharing the
code is often easier than trying to describe the idea.

Pushing a new branch is easy:  'git push origin remotebranch', which
is shorthand for 'git push origin localbranch:remotebranch'
Deleting branches is also easy:  'git push origin :remotebranch',
which means "push NULL to remotebranch"


I also agree with the assertion that some of our classes have probably
become "catch-all" buckets for functionality. I've been having similar
problems un-knotting the XML parsing code from the *Manager
initialization code. It's a bit of a mess.


---Brett.

[Rails-devel] Current implementation, branch Rails 2.0?

[Stefan F. <ste...@we...>]

On Wednesday, August 10, 2011 12:31:42 pm Erik Vos wrote:
> GameManager is the central action broker, and action execution is
> controlled in the various Round classes.
> That's the current architecture, and I have no plan to change that,
> certainly not without a clear vision on what could be a better architecture
> and a road map to get there.
> 
> Another reason is that I did not want to make this new feature specific for
> any particular type of action.
> I could have restricted its reach to company properties by putting this new
> method into CompanyManager (and subclass it for 18TN), but then this new
> phase-action mechanism would no longer be generic, which is what I want.
> 
> And thirdly: if we would start scattering around all kinds of action paths
> over all kinds of different managers, that would IMO rather complicate than
> simplify the structure of Rails.

Erik,
I do not agree here with your design:

In my understanding of Rails the term action is something different: All of 
them are user's actions and extend  the abstract class PossibleAction and 
belong to the rails.game.action package.

This new kind of "action" is in my eyes a named trigger which is activated by 
the train purchase. There is no need to pass the trigger through GameManager 
and Round classes with new methods and then call from the OperatingRound the 
method inside PublicCompany_TN.

My preferred solution would have been the possibility for PublicCompany_TN to 
register themselves with the PhaseManager and then get updated directly.

And only by convention actions are passed from GameManager to the Round 
(sub-)classes , but they design neither encourages nor enforces this:
Take for example the correction actions, they are processed in individual 
manager classes, and there is one for each action. If I have taken your 
approach all code inside the correction package would have been added to the 
GameManager too.

And that is my proposal or roadmap for those classes: Try to get GameManager 
focused on what is required for the top level class of the game (thus mainly 
storing the other component managers and interacting between them). Clean up 
the Rounds to include only the mechanisms to proceed from activity/step to the 
next and to switch between players/companies. All action processing should be 
done outside in individual components/classes.

For you it might seem easier to have everything in one place/file, but  I 
would prefer to refactor it somehow, before I am able to implement required 
adjustments for other games. 

Similar as it is difficult for you to write revenue code, it is difficult for 
others to change the Round or GameManager classes. But if nearly everything 
important is inside those classes, no one else will be able to help you 
implement the parts of new games that require changing those classes.

But if you split those classes into smaller pieces it makes it easier for 
outsiders (including myself) to understand the insides and it is less risky to 
change it without causing side effects.

See below for some stats if you do not believe my words.

My intention is not to blame you or to a blunt critique: It is my sole 
intention to help with coding. But I realize that I am mainly adding code 
around the core (revenue calculation, configuration, correction, states etc.) 
as I avoid touching the Round/GameManager  components.

And adding another algorithm for revenue gets a little boring if we are still 
waiting for 1825 and 1835 to work properly/fully.

However as I seem it hardly possible to refactor against a moving target (as 
you are stilling adding new functions to the core classes - and rightly do so, 
as long as there is no alternative), I suggest to create a new branch inside 
the git repo for a potential Rails 2.0. 

This branch would allow to refactor main parts without any fear to break the 
existing code/games/save files etc. It would also allow cleaning up from 
legacy code and components and a better support for unit testing.

In the main trunk new games/features could still be added to Rails 1.x, until 
Rails 2.0 is stable/mature enough.

Stefan


Some numbers on the size of classes in Rails.

The package Rails.game has 40960 instructions.

From those are the 5 largest
OperatingRound 7062 
PublicCompany 3817
GameManager 3623
StockRound 3200
MapHex 2962

And here you still have to consider that for PublicCompany and MapHex most of 
the code is in fact initialization and configuration.

Compare this to the top 6 largest packages (after rails.game)
rails.ui.swing 27949
rails.algorithms 12198
rails.game.action 5616
rails.ui.swing.hexmap 4792
rails.game.specifc._1856 4538
(from those the largest are again Round subclasses with a
sum of over 4000 instructions).
rails.game.specific._18EU 4136
(from those the largest are again Round subclasses with a 
sum of over 3000 instructions). 

Taken altogether it is not too far fetched that nearly 50% of all Rails.game 
code is part of the Round classes and subclasses. And the largest of it 
exceeds all other packages of rails except two.

And if you think about so important packages like move, model and state:
rails.game.move 1776
rails.game.model 863
rails.game.state 798

And those three packages consist of 10+ classes each.

Re: [Rails-devel] Automated test reports without currency identifier (19de64)

[brett l. <bre...@gm...>]

On Thu, Aug 11, 2011 at 9:11 AM, Stefan Frey <ste...@we...> wrote:
> I agree that it is the better solution to have UTF-8 working all the time
> (maybe Brett could check the setup of the git repo?)
> However it was easy to adjust the test.profile such that the reports do not
> contain the problematic yen and euro currency characters.
>

I'll check out what settings are available for that. I might just need
to write up a commit hook to auto-convert incoming changesets.

For the next month, I'm going to be crazy busy, but I'll try to
squeeze this in as soon as I can.

---Brett.

Re: [Rails-devel] Automated test reports without currency identifier (19de64)

[Stefan F. <ste...@we...>]

no, it does not. So either we have to make sure that UTF-8 is working 
everywhere (git-repo and all developers clones) or pipe the report output 
at the test run through a conversion to an ISO-8859-1 charset as in HTML.

On Thursday, August 11, 2011 06:14:25 pm Erik Vos wrote:
> But that doesn't fix the same problem with KKÖB in 18EU.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Thursday, August 11, 2011 6:12 PM
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Automated test reports without currency identifier
> > (19de64)
> > 
> > I agree that it is the better solution to have UTF-8 working all the time
> > (maybe Brett could check the setup of the git repo?) However it was easy
> 
> to
> 
> > adjust the test.profile such that the reports do not contain the
> 
> problematic
> 
> > yen and euro currency characters.
> > 
> > On Tuesday, August 09, 2011 06:46:06 pm John A. Tamplin wrote:
> > > On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...>
> > 
> > wrote:
> > > > The encoding (at least accoding to my editor) of the report files is
> > > > still UTF-8 and they open up in the editor correctly.
> > > > All tests report passed as well.
> > > > However to avoid those issues I suggest to remove the currency
> > > > indicator from the report files used for testing.
> > > > I can do the code change tomorrow.
> > > 
> > > It won't be just currency characters -- you would have to avoid all
> > > names in the game as well.
> > > 
> > > Better to make sure everything is always stored as UTF8 and
> > > interpreted as
> > > UTF8 and be done with it.
> 
> ---------------------------------------------------------------------------
> - --
> 
> > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> > administration capabilities and model configuration. Take the hassle out
> 
> of
> 
> > deploying and managing Subversion and the tools developers use with it.
> > http://p.sf.net/sfu/wandisco-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Route calculation: Train length heuristic

[Stefan F. <ste...@we...>]

Erik,
it is already implemented (in a local branch, otherwise I would have not been 
able to report running times). 

However I want to run some more tests before pushing it.

The answer to your question is no:I it does not require a train config 
attribute as the train domination is implemented as a Comparator (method) in 
the NetworkTrain class.

So the train conditions could be checked automatically, however there can be 
certain conditions in specific games that break the heuristic, for example 
bonuses that are only valid for specific trains (e.g. if in 18AL players 
decide to have the director assign the named train themselves).

As the heuristic is only necessary in games with very long trains (as in 1830, 
1856, 1870) I want to be on the safe side and only activate the heuristic in 
those games after some tests by providing a global switch as an attribute to 
the RevenueManager in game.xml.

Stefan


On Tuesday, August 09, 2011 11:14:47 am Erik Vos wrote:
> Stefan,
> 
> Do you plan to implement this heuristic in Rails?
> Would it require a new TrainType config attribute, like <TrainType
> name="6+6" ... dominates="6,5+5"/>?
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Tuesday, August 09, 2011 7:03 AM
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Route calculation: Train length heuristic
> > 
> > A year ago I suggested another heuristic to improve the speed of the
> > revenue calculation.
> > 
> > The idea is to use what 1830 players automatically do:
> > If you calculate a run for a 4 and a 3 train, you already know that you
> 
> will end
> 
> > up with a longer route (more stations) for the 4 train and a shorter
> > route
> 
> for
> 
> > the 3 train. Similar for running a Diesel and a 5 train.
> > 
> > However this knowledge is not taken into account by the current
> > algorithm. Things unfortunately are not that easy for all 18xx as it are
> > in 1830. For example in 1835 one cannot tell this ex-ante for a
> > combination of a
> 
> 5+5
> 
> > and a 6 train. That in fact is one the reasons why calculating the
> 
> Preussian
> 
> > routes is not an easy task.
> > 
> > Another exceptions are: If trains score differently for the same route
> > (Express (xE) and Double (xD) trains) or if hex trains run jointly with
> 
> standard
> 
> > trains.
> > 
> > ** The formal definition of train domination:
> > 
> > If the "better" train A can run all routes that the "weaker" train B and
> 
> train A
> 
> > scores identical revenue on all routes as B, then I define that train A
> > dominates train B.
> > 
> > If A dominates B I write this as A>B, otherwise the trains are either
> 
> identical
> 
> > (A=B) or neither dominates (A<>B).
> > 
> > If train A dominates train B, the length of the route of train A will
> 
> always be
> 
> > longer or at least equally long as that of train B.
> > (Length of the route is the number of stations scored.)
> > 
> > ** Examples should make this clearer.
> > 
> > In 1830 it is easy:  D>6>5>4>3>2
> > 
> > In 1835 it is
> > 6+6 > 5+5 > 4+4 > 3+3 > 2+2
> > 6 > 5 > 4 > 3 > 2
> > 6+6 > 6, 5+5 > 5, 4 +4 > 4, 3+3 > 3, 2+2 > 2
> > 6 > 3+3, 4 > 2+2
> > But for example: 6 <> 5+5, 5 <> 3+3 etc.
> > 
> > ** Implementation
> > The implementation is pretty straight forward and only requires a few
> 
> lines
> 
> > of code in the revenue calculator. The major change is to order the
> > trains
> 
> by
> 
> > the criteria "train domination". Then the calculator assigns the initial
> 
> train
> 
> > length for the dominated train not with the maximum length of that train,
> > but with the (current) route length of the dominating train. This ensures
> 
> that
> 
> > the dominating train will always have the longer route assigned.
> > 
> > ** Speed improvement
> > I did run the scenarios of Aliza Panitz 1856 triple Diesel of CGR
> 
> scenarios and
> 
> > came to the following running times (more statistics on number of routes
> > evaluated and when the best solution was found see below).
> > 
> > For the simpler network (A) running times decrease from around 5 minutes
> > to
> > 3.5 minutes (my CPU is more powerful than Alizas ...).
> > For the extensive network (B) running times decrease from around 1 hour
> > to around 30 minutes.
> > 
> > Overall the improvement it seems that the speed is improved by around 50%
> > to 200%, so time to wait is down by 33% to 66%, which is not bad.
> > 
> > But as it can be clearly seen by comparison with a double Diesel
> > scenarios
> 
> the
> 
> > exponential characteristic of the algorithm is still very clear.
> > 
> > So I still hope that John Tamplin can give some hints on his lost flow
> 
> algorithm
> 
> > for those who want to run triple Diesel more often.
> > 
> > Stefan
> > 
> > ** Stats
> > 
> > => Aliza Scenario 1856 A:
> > 31 vertices with 41 edges
> > 10 startvertices
> > 
> > Values:
> > Single D: 700
> > Double D: 920
> > Triple D: 1120
> > 
> > Single D: 0 second / 6.2k Evaluations, 6.2k Predictions
> > 
> > Without dominant trains:
> > Double D: 3 seconds / 1.3M Evaluations, 1.4M Predictions Triple D: 290
> > seconds / 114.9M Evaluations, 129.5M Predictions
> > (Solution: 25 seconds / 13.4M Evaluations, 14.7M Predictions)
> > 
> > With dominant trains:
> > Double D: 1 second / 323k Evaluations, 385k Predictions Triple D: 206
> 
> seconds
> 
> > / 87.4M Evaluations, 98.0M Predictions
> > (Solution: 20 seconds / 9.1M Evaluations, 10.0M Predictions)
> > 
> > => Aliza Scenario 1856 B:
> > 34 vertices with 50 edges
> > 10 startvertices
> > 
> > Values:
> > Single D: 790
> > Double D: 1280
> > Triple D: 1440
> > 
> > Single D: 0 second / 53.3k Evaluations, 53.3k Predictions
> > 
> > Without dominant trains:
> > Double D: 12 seconds / 4.8M Evaluations, 5.1M Predictions Triple D: 3551
> > seconds / 1473M Evaluations, 1709M Predictions
> > (Solution: 41 seconds / 16.9M Evaluations, 17.7M Predictions)
> > 
> > With dominant trains:
> > Double D: 5 seconds / 1.9M Evaluations, 2.3M Predictions Triple D: 1926
> > seconds / 832M Evaluations, 962M Predictions
> > (Solution: 27 seconds / 11.7M Evaluations, 12.3M Predictions)
> > 
> > => Scenario 1870:
> > This is the route network used for testing a year ago,
> > 
> > 23 vertices with 57 edges
> > 1 startvertex
> > 
> > Values:
> > Single 12: 380
> > Double 12: 690
> > Triple 12: 820
> > 
> > Single 12: 0 second / 11.5k Evaluations, 23.7k Predictions
> > 
> > Without dominant trains:
> > Double 12: 4 seconds / 1.4M Evaluations, 1.9M Predictions Triple 12: 104
> > seconds / 23.4M Evaluations, 61.6M Predictions
> > (Solution: 13 seconds / 3.2M Evaluations, 6.2M Predictions)
> > 
> > With dominant trains:
> > Double 12: 4 seconds / 1.2M Evaluations, 1.7M Predictions Triple 12: 49
> > seconds / 8.1M Evaluations, 30.0M Predictions
> > (Solution: 16 seconds / 3.0M Evaluations, 9.3M Predictions)
> 
> ---------------------------------------------------------------------------
> - --
> 
> > uberSVN's rich system and user administration capabilities and model
> > configuration take the hassle out of deploying and managing Subversion
> > and the tools developers use with it. Learn more about uberSVN and get a
> > free download at:  http://p.sf.net/sfu/wandisco-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automated test reports without currency identifier (19de64)

[Erik V. <eri...@xs...>]

But that doesn't fix the same problem with KKÖB in 18EU.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, August 11, 2011 6:12 PM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Automated test reports without currency identifier
> (19de64)
> 
> I agree that it is the better solution to have UTF-8 working all the time
> (maybe Brett could check the setup of the git repo?) However it was easy
to
> adjust the test.profile such that the reports do not contain the
problematic
> yen and euro currency characters.
> 
> 
> On Tuesday, August 09, 2011 06:46:06 pm John A. Tamplin wrote:
> > On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...>
> wrote:
> > > The encoding (at least accoding to my editor) of the report files is
> > > still UTF-8 and they open up in the editor correctly.
> > > All tests report passed as well.
> > > However to avoid those issues I suggest to remove the currency
> > > indicator from the report files used for testing.
> > > I can do the code change tomorrow.
> >
> > It won't be just currency characters -- you would have to avoid all
> > names in the game as well.
> >
> > Better to make sure everything is always stored as UTF8 and
> > interpreted as
> > UTF8 and be done with it.
> 
>
----------------------------------------------------------------------------
--
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> administration capabilities and model configuration. Take the hassle out
of
> deploying and managing Subversion and the tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Automated test reports without currency identifier (19de64)

[Stefan F. <ste...@we...>]

I agree that it is the better solution to have UTF-8 working all the time 
(maybe Brett could check the setup of the git repo?)
However it was easy to adjust the test.profile such that the reports do not 
contain the problematic yen and euro currency characters.


On Tuesday, August 09, 2011 06:46:06 pm John A. Tamplin wrote:
> On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...> wrote:
> > The encoding (at least accoding to my editor) of the report files is
> > still UTF-8 and they open up in the editor correctly.
> > All tests report passed as well.
> > However to avoid those issues I suggest to remove the currency indicator
> > from
> > the report files used for testing.
> > I can do the code change tomorrow.
> 
> It won't be just currency characters -- you would have to avoid all names
> in the game as well.
> 
> Better to make sure everything is always stored as UTF8 and interpreted as
> UTF8 and be done with it.

[Rails-devel] 18TN revenue calculation (4ba69a)

[Stefan F. <ste...@we...>]

I have added the civil war revenue modifier (removing the shortest train of a 
company at that time), so 18TN should be finished, except for checking if a 
company has no route at the time of civil war. For that case the revenue has 
to be adjusted manually.

To make this more transparent I allow static revenue modifiers now to add a 
comment to the detailed revenue message and did this in a few other cases 
(e.g. if a bonus was active for a company etc.)

Stefan

Re: [Rails-devel] How to clean up the Git index?

[Erik V. <eri...@xs...>]

A hard reset did it.  Thanks.
Fortunately I had nothing to commit or push, I just wanted a clean house.  Now I have.

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Wednesday, August 10, 2011 7:34 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] How to clean up the Git index?
> 
> On Wed, Aug 10, 2011 at 10:22 AM, Erik Vos <eri...@xs...> wrote:
> >> Try doing a "git diff" and see what lines it thinks are changed.
> >
> > None.  That's why I'm baffled.
> >
> > Erik.
> 
> 
> Strange.
> 
> You can always do a "git reset --hard origin/master", but this will destroy any
> local commits you haven't pushed.
> 
> A less destructive method is a simple "git reset --hard", which will reset any
> changes back to the state of your local HEAD.
> 
> ---Brett.
> 
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] How to clean up the Git index?

[brett l. <bre...@gm...>]

On Wed, Aug 10, 2011 at 10:22 AM, Erik Vos <eri...@xs...> wrote:
>> Try doing a "git diff" and see what lines it thinks are changed.
>
> None.  That's why I'm baffled.
>
> Erik.


Strange.

You can always do a "git reset --hard origin/master", but this will
destroy any local commits you haven't pushed.

A less destructive method is a simple "git reset --hard", which will
reset any changes back to the state of your local HEAD.

---Brett.

Re: [Rails-devel] How to clean up the Git index?

[Erik V. <eri...@xs...>]

> Try doing a "git diff" and see what lines it thinks are changed.

None.  That's why I'm baffled.

Erik.

Re: [Rails-devel] How to clean up the Git index?

[brett l. <bre...@gm...>]

On Wed, Aug 10, 2011 at 9:18 AM, Erik Vos <eri...@xs...> wrote:
> Brett (or anyone else knowing the answer),
>
> How can I remove incorrect 'modified' markers from files in the Index that
> should not be there because nothing has changed?
>
> I'm having this problem with 5 StockMarket.xml files.
> I don't know why Git thinks these files have changed (these are shown as
> modified by 'git status', but all diffs are empty).
>
> I tried 'git rm --cached' but that untracks the files.
>
> Erik.
>

Git will notice whitespace changes, such as tabs converted to spaces
or vice versa, as well as other non-visible changes, such as a change
from Unix-style carriage returns (CR) to Windows-style carriage
returns (CRLF).

Try doing a "git diff" and see what lines it thinks are changed.

---Brett.

[Rails-devel] How to clean up the Git index?

[Erik V. <eri...@xs...>]

Brett (or anyone else knowing the answer),

How can I remove incorrect 'modified' markers from files in the Index that
should not be there because nothing has changed?

I'm having this problem with 5 StockMarket.xml files.  
I don't know why Git thinks these files have changed (these are shown as
modified by 'git status', but all diffs are empty).

I tried 'git rm --cached' but that untracks the files.

Erik.

Re: [Rails-devel] Phase mgmt step 4, and 18TN Civil War (cee06b)

[Erik V. <eri...@xs...>]

Some answers below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]


> > 1. Phase management step 4: <Phase> can now have an <Action> child
> > with
> > (required) name and (optional) value attributes.
> > Each action causes gameManager.processPhaseAction (name, value) to be
> > called when that phase is activated.
> > GameManager in turn calls processPhaseAction(name, value) in the
> > current round.
> 
> I do not need to remind you that I am not happy that the Round mechanisms
> get more complicated again. Is there really no solution possible that
avoids
> putting phase mechanisms inside the rounds/gamemanager classes again?

GameManager is the central action broker, and action execution is controlled
in the various Round classes. 
That's the current architecture, and I have no plan to change that,
certainly not without a clear vision on what could be a better architecture
and a road map to get there.

Another reason is that I did not want to make this new feature specific for
any particular type of action.
I could have restricted its reach to company properties by putting this new
method into CompanyManager (and subclass it for 18TN), but then this new
phase-action mechanism would no longer be generic, which is what I want.

And thirdly: if we would start scattering around all kinds of action paths
over all kinds of different managers, that would IMO rather complicate than
simplify the structure of Rails.

> > 2. This new feature is used to implement 18TN Civil War (except the
> > revenue calculation).
> > The new code is in OperatingRound_18TN (updated) and
> > PublicCompany_18TN (new).
> > The latter method has a civilWar BooleanState that is set and unset
> > according to the 18TN rules.  This already works.
> 
> Again OperatingRound ;-)

Inevitable, as I'm overriding an existing OR method to implement this
specific 18TN feature.  Besides, OperatingRound_18TN already existed for
other purposes.

> So my solution will be that PublicCompany_18TN will implement a
> RevenueStaticModifier and will remove the shorter train
> 
> I assume that you have implemented the rule that a company with only one
> train (thus zero revenue) has its token unmoved instead of going left.

Yes.  It works.
 
> >
> > 3. To fully implement the 18TN rules, the CivilWar setting also
> > requires
> > publicCompany.hasRoute() to return true.
> > This is a new stub that always returns true (and is not used anywhere
> > else yet).
> > I hope we will once be able to detect route existence in the game
engine.
> 
> Existence of a route checking is easy to implement and is on my todo-list.
> I will add that asap.
> 
> >
> > Stefan, I trust you will now be able to finish 18TN completely by
> > implementing the effect of the Civil War on the revenue calculation.
> >
> > To check the company CivilWar status you could call its isCivilWar()
> > method directly , but from an architectural POV (client/server
> > separation) it would be preferable, if at all possible, to create an
> > Observer
> > (ViewObject) per company to register at the ModelObject
> > (=BooleanState) via the company getCivilWar() method.
> 
> No the push mechanism I use here is the RevenueStaticModifier (see
> above).

Fine.

Erik.

Re: [Rails-devel] Route calculation for huge runs

[Stefan F. <ste...@we...>]

On Wednesday, August 10, 2011 07:37:29 am John A. Tamplin wrote:
> On Wed, Aug 10, 2011 at 1:19 AM, brett lentz <bre...@gm...> wrote:
> > Personally, if y'all want to pitch in and use Rails to try out
> > different algorithms and see who can come up with the best one, I
> > think it would be fantastic. It may even be a good foundation for
> > supporting AI, which has also been a long-time dream. ;-)
> 
> AI is going to have to be able to very quickly (like in ms) evaluate
> possible runs in various scenarios, because it is going to have to evaluate
> many options and hopefully a few moves ahead.  For that, it doesn't have to
> be accurate, just reasonably close -- but it absolutely has to be
> blindingly fast.
> 
> For regular route calculation, I would hope it would be better than Simtex
> -- I frequently found incorrect runs.  If we get people relying on it and
> then they find it produces incorrect answers, then that will be a problem.
>  I would prefer to come up with some heuristic for deciding when the
> exponential approach will take too long, and then do some approximation and
> label it clearly as such.

The current setup is strongly optimized for the regular calculation (the graph 
is always created from scratch and there is no easy way to simply add or 
change a tile once it is created). 

This was somehow different from Alex' approach one year ago (what happened to 
his prototype?) who tried to keep the door wide open for AI.

I agree with John that a separate approach to route calculation for AI is 
optimal. For AI you are mainly interested in finding revenue increases by 
changing the graph in several steps, thus the strategy space is again 
exponentially larger. And then you have to rely on all kind of approximations 
and "non-correct" tree pruning. And you are allowed to do so for AI.

Stefan

Re: [Rails-devel] Phase mgmt step 4, and 18TN Civil War (cee06b)

[Stefan F. <ste...@we...>]

See my comments below.

As always the train not to run will chosen such that the revenue is optimized.

If the president wants another choice he can adjust the revenue. 

Interestingly 18TN is one the games where one stockholder can point out a 
better route and enforces the president to use that. Seems that the rules are 
slightly contradicting here, however I would use the general approach here 
that the more specific rule (civil war with president choice) would have 
priority here.

On Tuesday, August 09, 2011 11:18:30 pm Erik Vos wrote:
> I have implemented:
> 
> 1. Phase management step 4: <Phase> can now have an <Action> child with
> (required) name and (optional) value attributes.
> Each action causes gameManager.processPhaseAction (name, value) to be
> called when that phase is activated.
> GameManager in turn calls processPhaseAction(name, value) in the current
> round.

I do not need to remind you that I am not happy that the Round mechanisms get 
more complicated again. Is there really no solution possible that avoids 
putting phase mechanisms inside the rounds/gamemanager classes again?

> 
> 2. This new feature is used to implement 18TN Civil War (except the revenue
> calculation).
> The new code is in OperatingRound_18TN (updated) and PublicCompany_18TN
> (new).
> The latter method has a civilWar BooleanState that is set and unset
> according to the 18TN rules.  This already works.

Again OperatingRound ;-)
So my solution will be that PublicCompany_18TN will implement a 
RevenueStaticModifier and will remove the shorter train 

I assume that you have implemented the rule that a company with only one train 
(thus zero revenue) has its token unmoved instead of going left.

> 
> 3. To fully implement the 18TN rules, the CivilWar setting also requires
> publicCompany.hasRoute() to return true.
> This is a new stub that always returns true (and is not used anywhere else
> yet).
> I hope we will once be able to detect route existence in the game engine.

Existence of a route checking is easy to implement and is on my todo-list.
I will add that asap.

> 
> Stefan, I trust you will now be able to finish 18TN completely by
> implementing the effect of the Civil War on the revenue calculation.
> 
> To check the company CivilWar status you could call its isCivilWar() method
> directly , but from an architectural POV (client/server separation) it
> would be preferable, if at all possible, to create an Observer
> (ViewObject) per company to register at the ModelObject (=BooleanState)
> via the company getCivilWar() method.

No the push mechanism I use here is the RevenueStaticModifier (see above).

> 
> Erik.
> 
> 
> ---------------------------------------------------------------------------
> --- uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Route calculation for huge runs

[John A. T. <ja...@ja...>]

On Wed, Aug 10, 2011 at 1:10 AM, Stefan Frey <ste...@we...> wrote:

> However what I take from this is that most likely that a polynomial
> solution
> exists (as John was able to find one 24 years ago) to the diesel/12 train
> scenario and that the existing algorithm covers the exotic train cases.


It is certainly possible that I made some mistake, and the fact that I don't
have the code and can't remember the graph transform details makes it harder
to defend.  However, it definitely did give the correct result (as manually
calculated) in cases where Simtex gave the wrong answer, and it was quicker
on the same hardware.

However, I don't think it is worth much effort trying to recreate it,
because basically there are very few games which could make use of it
anyway.

-- 
John A. Tamplin

Re: [Rails-devel] Route calculation for huge runs

[Stefan F. <ste...@we...>]

> 
> Also, don't forget... the big difference between Comp Sci theory and
> real world implementations, is that in the real world it's
> occasionally possible (and completely acceptable) to cheat.
> 
> If we can find a "good enough" algorithm that at least gets us mostly
> correct answers most of the time while still avoiding a brute force
> method, I think that has a certain amount of value. This is especially
> true if we continue to allow users to be the final arbitrator on what
> their run values really are.

Brett,
I think a "good enough" algorithm defined by you above is not the goal and the 
current algorithm is already better than your "good enough" algorithm.

The algorithm itself (as a descendant from brute-force enhanced by heuristics 
for tree pruning) should always result the optimal solution.
If a user is able to point out a better solution this is a bug and should be 
filed as such.

The previous discussion on the list convinced me that a "good enough" 
algorithm would be never enough to make people comfortable to use Rails.

I know that some people claim to have found calculation errors of Rails, but 
when asked for save files I never received one.
I think you should not give Rails a worse reputation than it actually 
deserves.

> 
> Even Simtex's 1830 game didn't have perfect route calculation
> algorithms, and I've found a number of late game positions for which
> it would suggest sub-optimal routes.

Do you have save files for those cases? I would like to recreate the track 
configuration with Rails.

Stefan

Re: [Rails-devel] Route calculation for huge runs

[John A. T. <ja...@ja...>]

On Wed, Aug 10, 2011 at 1:19 AM, brett lentz <bre...@gm...> wrote:

> Personally, if y'all want to pitch in and use Rails to try out
> different algorithms and see who can come up with the best one, I
> think it would be fantastic. It may even be a good foundation for
> supporting AI, which has also been a long-time dream. ;-)


AI is going to have to be able to very quickly (like in ms) evaluate
possible runs in various scenarios, because it is going to have to evaluate
many options and hopefully a few moves ahead.  For that, it doesn't have to
be accurate, just reasonably close -- but it absolutely has to be blindingly
fast.

For regular route calculation, I would hope it would be better than Simtex
-- I frequently found incorrect runs.  If we get people relying on it and
then they find it produces incorrect answers, then that will be a problem.
 I would prefer to come up with some heuristic for deciding when the
exponential approach will take too long, and then do some approximation and
label it clearly as such.

-- 
John A. Tamplin

Re: [Rails-devel] Route calculation for huge runs

[brett l. <bre...@gm...>]

On Tue, Aug 9, 2011 at 10:10 PM, Stefan Frey <ste...@we...> wrote:
> see below
>
> On Wednesday, August 10, 2011 06:54:58 am John A. Tamplin wrote:
>> On Wed, Aug 10, 2011 at 12:04 AM, Bill Rosgen <ro...@gm...> wrote:
>> > Is the problem really solvable?  The planar cubic hamiltonian path
>> > problem is NP-complete (see Garey, Johnson, and Tarjan 1976, which seems
>> > to be available at
>> > http://www.cs.princeton.edu/courses/archive/spr04/cos423/handouts/the%20p
>> > lanar%20hamiltonian.pdf).  The title of the paper involves cycles, but
>> > the text on page 713 claims it holds also for paths.  I have not
>> > verified the results of the paper, but it appears in a very good journal
>> > and so is likely to be correct.
>> >
>> > I think the problem is equivalent to optimizing the run of only one
>> > diesel on such a graph.  Given any planar graph with degree 3, it can be
>> > implemented as an 18xx map with cities as vertices and track as edges,
>> > though the map may get pretty large (though still polynomial in the
>> > number of cities).  Imagine such a map with only one company (with a
>> > token somewhere) that owns one diesel.  That train can hit every city if
>> > and only if there is a Hamiltonian path in the original graph.
>>
>> I don't think it is equivalent to Hamiltonian path on an arbitrary graph,
>> and there are polynomial solutions for Hamiltonian path on many types of
>> restricted graphs.  Also, you aren't actually asking is there a path that
>> visits all cities but instead what is the best path that can be obtained.
>>
>> > Practically this doesn't say that much, as we don't have arbitrarily
>> > large graphs, and many of the trains in 18xx games run for some constant
>> > length, but it might imply that a general purpose poly-time algorithm is
>> > going to be difficult to find.
>>
>> I agree, in particular I think being able to skip stops and double an
>> arbitrary stop are things that would make anything short of brute
>> force intractable.
>
>
> This reminds me of getting involved into discussions of asymptotic behaviors
> by the econometrics theory people if I ask a question how to solve an
> econometric problem in an empirical applied context: I feel intimidated and
> stupid ;-)
>
> And usually the number of answers exceeds the number of questions by a large
> multiple...
>
> However what I take from this is that most likely that a polynomial solution
> exists (as John was able to find one 24 years ago) to the diesel/12 train
> scenario and that the existing algorithm covers the exotic train cases.
>
>

Also, don't forget... the big difference between Comp Sci theory and
real world implementations, is that in the real world it's
occasionally possible (and completely acceptable) to cheat.

If we can find a "good enough" algorithm that at least gets us mostly
correct answers most of the time while still avoiding a brute force
method, I think that has a certain amount of value. This is especially
true if we continue to allow users to be the final arbitrator on what
their run values really are.

Even Simtex's 1830 game didn't have perfect route calculation
algorithms, and I've found a number of late game positions for which
it would suggest sub-optimal routes.

Personally, if y'all want to pitch in and use Rails to try out
different algorithms and see who can come up with the best one, I
think it would be fantastic. It may even be a good foundation for
supporting AI, which has also been a long-time dream. ;-)

---Brett.