rails-devel — List for discussion of Rails development

Re: [Rails-devel] Route calculation validations

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

Hi Alex,
I have attached a document that contains the detailed numbers for several 
train combinations without and with the revenue prediction active.

The following figures are defined:
revenue evaluation: how often the revenue of all trains is evaluated
edges travelled: how many edges were followed during the search
predictions: how often the potential maximum revenue was predicted.

My desktop is even slower as my laptop, as it is slightly older and has an AMD 
processor.

It clearly shows that revenue predictions is strongest for train combinations 
and non-diesel trains. Running a diesel alone is not any faster, unless an 
optimal solution is found (early).

Stefan

I sent that to the develop list, as others might also be interested in those 
numbers. I extract the main figures below,
all runs on the test scenario A.

8 train alone:
without prediction: 3.8k evaluations, 16.4k edges, time: < 1 sec
with prediction: 62 evaluations, 858 predictions, 2.3k edges, < 1 sec

8 and 10 trains:
without prediction: 1.9M evaluations, 11.0M edges, time: 90 sec
with prediction: 25k evaluations, 143k predictions, 387k edges, time: 4 sec

This clearly shows the strong increase of possible solutions, if more than one 
train is involved. It is around 1:500!

Diesel train:
without prediction: 424k evaluations, 3.3M edges, time: 25 sec
with prediction: 335k evaluations, 753k predictions, 2.6M edges, time: 23 sec
(In this example an optimal solution is found, but late).

A diesel is less complicated than the combination of an 8 and 10, but the 
revenue prediction does no help.

Diesel and a 6 train:
without prediction: 7.3M evaluations, 52.5M edges, time: 480 sec
with prediction: 231k evaluations, 2.8M predictions, 6.2M edges, time: 56 sec

Adding a 6 train, increases the running time by 20 without prediction, but 
only a little more than doubles with prediction.



On Sunday 18 April 2010 17:44:04 you wrote:
> Hi Stefan,
>
> I would agree about the name of the first number.
>
> (1) should be ok, I do the same, and there is no good reason for the
> algorithm to try evaluating route that just extend already evaluated route
> by some stations the train can't reach anyway. Or we could run the test on
> "express" train that can skip anything. Express trains (or any train
> capable of skipping cities) actually make me wonder what are possible
> rules about visiting the same hex. In some games train is not allowed to
> visit the same hex twice (when there are 2 separate cities on the tile).
> If there is any game with this rule and with express trains, then there's
> a question - if the train skips one city in the hex and counts another -
> is it valid route?
>
> (2) I apply the same method to the routes, but I didn't evaluate "half"
> routes - I only evaluate complete route (consisting of those 2 parts). How
> can you do differently? - There might be bonus for visiting 2 cities in
> different halves, or something like east-west run.
>
> If it's difficult to extract this number from your code now, we could set
> up example with the station in the dead-end, so there's only one way to
> leave it.
>
> Number of segments is relevant to the two-phased approach only. It is
> number of edges in the "coarse" graph (which is the same as number of
> distinct ways to travel between any pair of cities). You were asking about
> this number earlier to evaluate amount of memory that would need to be
> stored.
>
> I've also done profiling and it appears that storing segment exclusions as
> a vector of segments excluded by each segment is fine - this is not a
> bottleneck. So I haven't tried 2D array of booleans approach. But maybe I
> should try some different cases (for example set of 4 trains (2,2,3 and 3)
> - that may have a bottleneck in different places comparing to the case of
> few long trains).
>
> Thanks,
> Alex.
>
> On Sun, 18 Apr 2010 13:28:24 -0600, Stefan Frey <ste...@we...> wrote:
> > Hi Alex,
> > I would call the first statistic "number of  route evaluations" and it
> > counts
> > every call to the evaluation function. This figure is also available for
> > multiple-train runs. If we have the same number, it is almost sure that
> > the
> > two algorithms work identical. If not, it proves nothing, see below.
> >
> > Potential problems:
> > 1) I terminate trains as soon as possible, thus numbers depend on the
> > sequence
> > of vertexes visited.
> >
> > 2) I have train runs divided in two half trains: First the head train
> > starts
> > and each station the train can return to its start token and then the
> > bottom
> > train runs. To avoid duplication of routes (due to symmetry) the bottom
> > train
> > can only start to the side with increased orientation. If I remember
> > that is
> > a different approach to yours.
> >
> > So if we want to compare figures we have to run a train with infinite
> > length
> > (to avoid termination) and is not allowed to run twice from the start
> > vertex.
> >
> > I will have to adjust my codes to accommodate for such a test.
> >
> > The other statistic I am not fully clear about: Wat is exactly the
> > number of
> > segments? If this is related to the two-phase approach I assume this is
> > the
> > maximum number of connections between two stations on the map?
> > And I guess, that this might be the answer to the unrelated question I
> > raised
> > before. This strengthens the case of your approach. I will implement it
> > as
> > soon as I have some time left, which will be most likely after the next
> > release.
> >
> > Stefan
> >
> > On Sunday 18 April 2010 06:34:51 you wrote:
> >> Hi Stefan,
> >>
> >> I thought it might be useful to compare how many routes we try during
> >> the
> >> complete route search. We should be getting the same number. If we are
> >> not
> >> it will indicate that one of us (or both) have a bug. I suppose to test
> >> it
> >> we would need to run a single sufficiently long train (or maybe try for
> >> various train lengths) on the same track.
> >>
> >> I've also checked on number of segments in two-phased approach. In the
> >> scenario B there are just 153 segments.
> >>
> >> Thanks,
> >> Alex.

Re: [Rails-devel] Playtest: 4-player 1835 in Rails 1.2.2 - A dozen newbugs!

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

On Sun, Apr 18, 2010 at 7:11 AM, Chris Shaffer <chr...@gm...> wrote:
>> Now the second stock round begins, and very annoyingly, the main window
>> (showing player holdings and company prices) disappears, leaving only the
>> "start round" window and the map, with no way to get the main window back
>> since the options menu disappeared with it, so we have to make our
>> decisions
>> without knowing who owns what.  Never do this!!  No window EVER has
>> business
>> disappearing unless a human explicitly orders it to close!!
>>
>>> [EV] I agree, but others have ruled differently in the past. I'm all for
>>> it
>>> to keep all windows open.
>>> Anyway, you can always raise a window from the Game Status Options menu.
>
> If this discussion could be reopened, I would vote strongly in favor of
> opening all windows at game start and keeping them open.  Explaining that
> you can find the windows in the options menu is the first thing I have to do
> when telling people how to use the game.   The first thing I do when I start
> Rails is open all the windows.
>
> At the very least, rename the menu item from "Options" to "Windows."  The
> so-called options are "Set Scale" which has never been activated to my
> knowledge - it is always greyed out - and the various "Windows" and thus are
> not actually options at all.
>
> --
> Chris
>

Having this behavior as an option seems to make sense.  The original
idea was, as with the Simtex game, show the player "current"
information and hide the rest.

The Set Scale option is a long-standing bug in the MapWindow that needs fixing.

---Brett.

Re: [Rails-devel] Junit reports broken test cases

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

Fixed two bugs in the Erie tile-laying and token-jumping case:

- the code to prevent one brown OO city to pick up both green OO
connections, had been commented out in Rails 1.0.5 for unexplained reasons.
Guess it's my error (mea culpa).

- City.relatedStation should have been a State variable but wasn't. This
occasionally caused the cities (and hence the tokens) to be swapped after an
Undo (or rather: not be unswapped by the Undo). 
I haven't seen any token-swapping cases yet that are not caused by an Undo.
Sorry, no time for thorough testing these days.

Erik.

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Friday 16 April 2010 23:30
To: 'ste...@we...'; 'Development list for Rails: an 18xx game'
Subject: RE: Junit reports broken test cases

These two files reflect identical game positions, both having Erie green and
C&A brown. 
Indeed one brown OO tile lay let the Erie token jump, but perhaps even worse
is that several wrong brown tile lays are allowed.
That wasn't so in the past, so I wonder what might have broken that logic.

Re: [Rails-devel] Playtest: 4-player 1835 in Rails 1.2.2 - A dozen newbugs!

[Chris S. <chr...@gm...>]

>
> Now the second stock round begins, and very annoyingly, the main window
> (showing player holdings and company prices) disappears, leaving only the
> "start round" window and the map, with no way to get the main window back
> since the options menu disappeared with it, so we have to make our
> decisions
> without knowing who owns what.  Never do this!!  No window EVER has
> business
> disappearing unless a human explicitly orders it to close!!
>
> [EV] I agree, but others have ruled differently in the past. I'm all for it
>> to keep all windows open.
>> Anyway, you can always raise a window from the Game Status Options menu.
>>
>
If this discussion could be reopened, I would vote strongly in favor of
opening all windows at game start and keeping them open.  Explaining that
you can find the windows in the options menu is the first thing I have to do
when telling people how to use the game.   The first thing I do when I start
Rails is open all the windows.

At the very least, rename the menu item from "Options" to "Windows."  The
so-called options are "Set Scale" which has never been activated to my
knowledge - it is always greyed out - and the various "Windows" and thus are
not actually options at all.

--
Chris

Please consider the environment before printing this e-mail.

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

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

I like the principle of highlighting, but I'm not too fond of it's current
appearance.
A bit too intrusive and a bit too pinkish (yes, I know it's magenta).

What about a smaller and red border? 
So that 'selected' (wide red border) also visually becomes looking like the
fulfillment of 'selectable' (narrow red border)?

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Sunday 18 April 2010 13:10
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

I know the route awareness code isn't enforced yet, but I think
alongside revenue calculation that an option should exist to disable
that before shipping code with it in.  One of the guys I played with
didn't like the hex highlighting on company operate as it felt it
might highlight potential expansion that a player hasn't noticed and
thus disadvantages those who have been paying careful attention to
tile laying.

Personally I like it, but given that is now a 50% for and 50% against
(sample of 2 ;)) I'd say it's right to give people the option to not
have it.

Phil

On 17 April 2010 20:49, Erik Vos <eri...@xs...> wrote:
> I consider 1835 "almost playable" by now. Main things left to do:
> - PR operation in its first OR (yes/no)
> - closing rules of some privates (a correction mode to close a private
might
> come in handy)
> - specific rules of some of the already included variants
> - perhaps more variants
>
> Erik
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday 17 April 2010 17:04
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>
> Aliza,
> this reminds me of the suggested changes of the implemention levels as
> discussed some time ago for the next release. It seems to come close to
what
>
> you have in mind.
>
> So far the opinions for the individual 18xx were:
>
> 1825: D
> 1830: B/A
> 1835: D
> 1851: B
> 1856:
> 1870: D
> 1889: B
> 18AL: B
> 18EU: C/B
>
> With A=mature, B=fully playable, C=almost playable, D=experimental.
> (See definitions below)
>
> There has not been any comment on the level of 1856 with respect to the
> scaling above. And keep in mind that even if the individual 18xx might be
> stable, Rails itself is still not feature complete, thus even stable 18xx
> might be impacted from time to time.
>
> Stefan
>
> A) Mature
> - Several independent plays until the end reported
> - Full implementation of the ruleset
> - All possible moves are available
> - No illegal move possible (except tile and token lays, revenue
calculation)
> => Serious ftf play possible
> => pbem play possible
>
> B) Fully Playable
> - Full implementation of the ruleset
> - All possible moves are available
> - Might still allow a few illegal moves (in addition to tile and token
lays,
> revenue calculation)
> => Serious ftf play possible, but bugs are possible
> => use with caution for pbem play, version incompatibilities possible
>
> C) Almost Playable
> - Nearly complete implementation of the ruleset
> - Not all possible moves are available
> - Illegal moves are possible
> => Serious testing possible, do not expect to complete a game
> => not recommended for pbem play
>
> D) Experimental
> - Rules and components are incomplete
> => Some testing possible
>
>
>
> On Friday 16 April 2010 22:25:41 Aliza Panitz wrote:
>> Is there going to be a Rails release with this bug fix in it? (We're
>> trying to decide how/whether to continue the game this bug was
>> reported on...)
>>
>> 1856 has been marked as "fully supported" since Rails 1.0.7 and I'm
>> still struggling to complete PbEM games I started in November...
>> perhaps there should be another game status, "first release" or
>> "playtesting needed" or something, to denote games that are mostly
>> complete but for which there has been no extensive playtesting.
>>
>>  - Aliza
>>
>> On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
>> > Never mind, I could reproduce the problem as described below, and have
>> > fixed it.
>> > Can’t upload it now (SVN seems down) so that will be done tomorrow.
>> >
>> > Erik.
>> >
>> > -----Original Message-----
>> > From: Erik Vos [mailto:eri...@xs...]
>> > Sent: Friday 26 March 2010 00:00
>> > To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
>> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>> >
>> > Ah, you mean that sales of 15% and 5% have added up?
>> > If that is what has happened, I think I know what has caused this.
>> > A saved file would of course help a lot...
>> >
>> > Erik.
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Joshua Gottesman [mailto:jos...@gm...]
>> > Sent: Thursday 25 March 2010 22:56
>> > To: Aliza Panitz
>> > Cc: Development list for Rails: an 18xx game
>> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>> >
>> > Yeah, I didn't even notice that.  I just expected it to keep the price
>> > the same.  I suspect what happened is it counted your 15% and held the
>> > 1/2 share and then combined that with my 1/2 share for another price
>> > drop.  Which is incorrect.
>> >
>> > On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...>
>> >
>> > wrote:
>> >> Rails 1.2.2 bug:
>> >>
>> >> Selling a single 5% share of the CGR to the pool should not have
>> >> changed the stock
>> >> price.
>> >>
>> >> To quote the rules:
>> >>
>> >> ==============
>> >> The share value tokens move:
>> >>
>> >> Down one row for each full 10% share sold either during a stock round
>> >> or during a forced sale by a company president. The sale of a single
>> >> 5% share does not affect the share value token. Sales of multiple 5%
>> >> shares move the share value token
>> >> ==============
>> >>
>> >> To quote the game report:
>> >> ]  Joshua sells a 5% share of CGR to Pool for $90.
>> >> ] CGR price goes from $90(E2) to $80(E3).
>> >>
>> >>
>> >> I'll file an official bug later if nobody else gets to it first.
>> >>
>> >>  - Aliza
>> >>
>> >> 2010/3/25 Joshua Gottesman <jos...@gm...>:
>> >> - Hide quoted text -
>> >>
>> >>> ==================
>> >>> Start of Stock Round 6
>> >>> ==================
>> >>> Aliza has the Priority Deal
>> >>>
>> >>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
>> >>> CGR price goes from $100(E1) to $90(E2).
>> >>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
>> >>> Joshua sells a 5% share of CGR to Pool for $90.
>> >>> CGR price goes from $90(E2) to $80(E3).
>> >>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank
>> >
>> >
> -------------------------------------------------------------------------
>> >--- --
>> > Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> >
> -------------------------------------------------------------------------
>> >--- --
>> > Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> >
> -------------------------------------------------------------------------
>> >----- Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>
---------------------------------------------------------------------------
>>--- Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
>
----------------------------------------------------------------------------
> --
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
--
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

----------------------------------------------------------------------------
--
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Playtest: 4-player 1835 in Rails 1.2.2 - A dozen newbugs!

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

Thanks for this extensive playtest report. 

I have a few answers now, see below, and will check out the other points
later. 
A file saved around the time that you quit would help a lot.

Please note that 1835 is still marked "Partly playable". As much
functionality has recently been added, it's close to being marked "Almost
playable".

Erik.

-----Original Message-----
From: John David Galt [mailto:jd...@di...] 
Sent: Sunday 18 April 2010 10:13
To: rai...@li...
Subject: [Rails-devel] Playtest: 4-player 1835 in Rails 1.2.2 - A dozen
newbugs!

<yet unanswered complaints stripped for now>

The program is still using annoying 3-letter abbrevs for most companies.

[EV] Will be fixed when 1835 development is considered finished, as this
change will invalidate all existing (test) saved files.

It's also still listing X-Y coordinates for par values as well as current
values (which is wrong in all games that have par values).

[EV] Don't see what is 'wrong' here. You might find it annoying to see these
never-changing coordinates, and I would sympathize with that. Perhaps I even
might do something about it.

Now the second stock round begins, and very annoyingly, the main window
(showing player holdings and company prices) disappears, leaving only the
"start round" window and the map, with no way to get the main window back
since the options menu disappeared with it, so we have to make our decisions
without knowing who owns what.  Never do this!!  No window EVER has business
disappearing unless a human explicitly orders it to close!!

[EV] I agree, but others have ruled differently in the past. I'm all for it
to keep all windows open.
Anyway, you can always raise a window from the Game Status Options menu.

At this point I notice a map error.  Hex G1 is missing.  In the actual game,
G1 is a preprinted brown (or, if you prefer, gray) hex with a sharp-turn
track connecting Dusseldorf and Essen.  Without it, most of the green XX
tiles become unplayable in Essen, and Dusseldorf can never upgrade to brown,
so I have to call this one a major error.

[EV] Correct, my oversight. Will be added.

When it's time for M6 to upgrade Kiel, I see my first tile error: the
program offers to place #12, #14, #15, and #206 in Kiel.  Only 12 is legal,
of course.

[EV] Right, but the tiles display logic currently only knows about the
upgrade chart. You'll see soon enough what happens if you attempt to lay a
non-fitting tile. This item might be addressed sometime in the future, but
it can't seriously be called an 'error'.

*  I am not allowed to nationalize By shares from other people even though
   I have 60%.
*  When somebody does sell By, I'm not allowed to buy them then either, so
   apparently the program still imposes a 60% holding limit in 1835.

Finally, M2 buys the first 4 train.  The 2 trains disappear and he is forced
to discard a train of his choosing, but he is NOT offered a chance to form
the Pr.

[EV] Nationalisation, PR formation and the 100% limit have been implemented
only very recently, and will be in the next version.

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

[Phil D. <de...@gm...>]

I know the route awareness code isn't enforced yet, but I think
alongside revenue calculation that an option should exist to disable
that before shipping code with it in.  One of the guys I played with
didn't like the hex highlighting on company operate as it felt it
might highlight potential expansion that a player hasn't noticed and
thus disadvantages those who have been paying careful attention to
tile laying.

Personally I like it, but given that is now a 50% for and 50% against
(sample of 2 ;)) I'd say it's right to give people the option to not
have it.

Phil

On 17 April 2010 20:49, Erik Vos <eri...@xs...> wrote:
> I consider 1835 "almost playable" by now. Main things left to do:
> - PR operation in its first OR (yes/no)
> - closing rules of some privates (a correction mode to close a private might
> come in handy)
> - specific rules of some of the already included variants
> - perhaps more variants
>
> Erik
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday 17 April 2010 17:04
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>
> Aliza,
> this reminds me of the suggested changes of the implemention levels as
> discussed some time ago for the next release. It seems to come close to what
>
> you have in mind.
>
> So far the opinions for the individual 18xx were:
>
> 1825: D
> 1830: B/A
> 1835: D
> 1851: B
> 1856:
> 1870: D
> 1889: B
> 18AL: B
> 18EU: C/B
>
> With A=mature, B=fully playable, C=almost playable, D=experimental.
> (See definitions below)
>
> There has not been any comment on the level of 1856 with respect to the
> scaling above. And keep in mind that even if the individual 18xx might be
> stable, Rails itself is still not feature complete, thus even stable 18xx
> might be impacted from time to time.
>
> Stefan
>
> A) Mature
> - Several independent plays until the end reported
> - Full implementation of the ruleset
> - All possible moves are available
> - No illegal move possible (except tile and token lays, revenue calculation)
> => Serious ftf play possible
> => pbem play possible
>
> B) Fully Playable
> - Full implementation of the ruleset
> - All possible moves are available
> - Might still allow a few illegal moves (in addition to tile and token lays,
> revenue calculation)
> => Serious ftf play possible, but bugs are possible
> => use with caution for pbem play, version incompatibilities possible
>
> C) Almost Playable
> - Nearly complete implementation of the ruleset
> - Not all possible moves are available
> - Illegal moves are possible
> => Serious testing possible, do not expect to complete a game
> => not recommended for pbem play
>
> D) Experimental
> - Rules and components are incomplete
> => Some testing possible
>
>
>
> On Friday 16 April 2010 22:25:41 Aliza Panitz wrote:
>> Is there going to be a Rails release with this bug fix in it? (We're
>> trying to decide how/whether to continue the game this bug was
>> reported on...)
>>
>> 1856 has been marked as "fully supported" since Rails 1.0.7 and I'm
>> still struggling to complete PbEM games I started in November...
>> perhaps there should be another game status, "first release" or
>> "playtesting needed" or something, to denote games that are mostly
>> complete but for which there has been no extensive playtesting.
>>
>>  - Aliza
>>
>> On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
>> > Never mind, I could reproduce the problem as described below, and have
>> > fixed it.
>> > Can’t upload it now (SVN seems down) so that will be done tomorrow.
>> >
>> > Erik.
>> >
>> > -----Original Message-----
>> > From: Erik Vos [mailto:eri...@xs...]
>> > Sent: Friday 26 March 2010 00:00
>> > To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
>> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>> >
>> > Ah, you mean that sales of 15% and 5% have added up?
>> > If that is what has happened, I think I know what has caused this.
>> > A saved file would of course help a lot...
>> >
>> > Erik.
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Joshua Gottesman [mailto:jos...@gm...]
>> > Sent: Thursday 25 March 2010 22:56
>> > To: Aliza Panitz
>> > Cc: Development list for Rails: an 18xx game
>> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>> >
>> > Yeah, I didn't even notice that.  I just expected it to keep the price
>> > the same.  I suspect what happened is it counted your 15% and held the
>> > 1/2 share and then combined that with my 1/2 share for another price
>> > drop.  Which is incorrect.
>> >
>> > On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...>
>> >
>> > wrote:
>> >> Rails 1.2.2 bug:
>> >>
>> >> Selling a single 5% share of the CGR to the pool should not have
>> >> changed the stock
>> >> price.
>> >>
>> >> To quote the rules:
>> >>
>> >> ==============
>> >> The share value tokens move:
>> >>
>> >> Down one row for each full 10% share sold either during a stock round
>> >> or during a forced sale by a company president. The sale of a single
>> >> 5% share does not affect the share value token. Sales of multiple 5%
>> >> shares move the share value token
>> >> ==============
>> >>
>> >> To quote the game report:
>> >> ]  Joshua sells a 5% share of CGR to Pool for $90.
>> >> ] CGR price goes from $90(E2) to $80(E3).
>> >>
>> >>
>> >> I'll file an official bug later if nobody else gets to it first.
>> >>
>> >>  - Aliza
>> >>
>> >> 2010/3/25 Joshua Gottesman <jos...@gm...>:
>> >> - Hide quoted text -
>> >>
>> >>> ==================
>> >>> Start of Stock Round 6
>> >>> ==================
>> >>> Aliza has the Priority Deal
>> >>>
>> >>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
>> >>> CGR price goes from $100(E1) to $90(E2).
>> >>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
>> >>> Joshua sells a 5% share of CGR to Pool for $90.
>> >>> CGR price goes from $90(E2) to $80(E3).
>> >>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank
>> >
>> >
> -------------------------------------------------------------------------
>> >--- --
>> > Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> >
> -------------------------------------------------------------------------
>> >--- --
>> > Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> >
> -------------------------------------------------------------------------
>> >----- Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
> ---------------------------------------------------------------------------
>>--- Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ----------------------------------------------------------------------------
> --
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Playtest: 4-player 1835 in Rails 1.2.2 - A dozen new bugs!

[John D. G. <jd...@di...>]

I tried a four player game of 1835 using Rails 1.2.2 on Saturday 2010-04-17.

When I selected the game 1835, my entry of four player names was erased as
the number of player slots changed from 5 to 7.  All were once again "None"
and had to be re-entered.

No variants were available (or if the option existed I couldn't see it).

The opening stock round went normally, though it would have been helpful to
have the normal visual display of the Start Packet.  The entire Start Packet
sold out except the Ostbayerische/By share combination.  (The one player who
had the money for it had LD/2Sx/M3/M6, and naturally didn't want the By to
float right away, so he correctly passed.)

The program is still using annoying 3-letter abbrevs for most companies.
It's also still listing X-Y coordinates for par values as well as current
values (which is wrong in all games that have par values).

Other annoying things about the main window:  Under "Company details" the
"Revenue" and "Trains" columns are wastefully wide, and resizing the window
doesn't fix that: the player percentage columns shrink to unreadability
instead!  (I'm guessing this is because of the line showing all train
prices, but there's plenty of room for those to take up to three lines.)

It wasn't until most of the minor companies had run that I noticed a major
error: the program had gone ahead and floated By.  That is seriously wrong.
(I understand there are people who play a house rule that it always floats
in the first round, but in the rules as written it definitely does not
unless all 50% in the start packet is purchased.)  Since I wanted more of a
test than I would get by stopping here, I continued the game but had By do
nothing in round 1 except to buy a 2 train.  This means By's price will be
one square too far left for the rest of the game.

Now the second stock round begins, and very annoyingly, the main window
(showing player holdings and company prices) disappears, leaving only the
"start round" window and the map, with no way to get the main window back
since the options menu disappeared with it, so we have to make our decisions
without knowing who owns what.  Never do this!!  No window EVER has business
disappearing unless a human explicitly orders it to close!!

When the Ostbayerische is purchased, the main window reappears.

For the rest of SR2 the button does not light up that would allow any player
to sell By shares.  Since the program considers (wrongly) that By has
operated, this must be another bug.  Also, the player who bought LD is shown
as having "20%" of Sx, not "20%P" nor "20%PU" which would be correct.

The map window now says it is "Operating Round 1.1 (1 of 1)" again.
Apparently the fact that the Start Packet didn't sell out the first time has
confused the program.  This may be why no one was allowed to sell By shares.

By is now, correctly, allowed to place a token with the Nurnberg-Furth before
laying tiles.

By is still, wrongly, asked if he wants to place a token with the Pfalzbahnen
without having laid a tile there (and without Ba having floated).

Companies are correctly prevented from buying trains from one another since a
3 has not been purchased.

In SR3 (mislabeled STOCK ROUND 2 on the title bar of the main window) the
players are allowed to sell By shares.  LD is correctly closed because Sx
bought a train.  The player who began with LD is still shown with "20%" of Sx
until he buys a third share, then it changes to the correct "30%PU".

(I won't mention the round number errors again but they continue to be too
low by one, for both stock and operating rounds, for the rest of the game.)

At the end of SR3, By and Sx, which were both in the same price square, both
go up for being all owned, but By moves from underneath Sx to on top for no
apparent reason.  Another bug.

The stock-price chart then disappears (and goes on disappearing after each
stock round), but I notice upon its next reappearance that the prices on it
are only updated at the beginning of stock rounds -- not each time they move.
I suppose this only matters if there is no way to make the chart reappear
during operating rounds, but it is still annoying.

At this point I notice a map error.  Hex G1 is missing.  In the actual game,
G1 is a preprinted brown (or, if you prefer, gray) hex with a sharp-turn
track connecting Dusseldorf and Essen.  Without it, most of the green XX
tiles become unplayable in Essen, and Dusseldorf can never upgrade to brown,
so I have to call this one a major error.

When it's time for M6 to upgrade Kiel, I see my first tile error: the
program offers to place #12, #14, #15, and #206 in Kiel.  Only 12 is legal,
of course.

In the next stock round, when Ba forms, I notice several things:
*  40% of Pr does become available for sale at the correct time.
*  When a new company becomes available for sale, it shows "1.." in the IPO
   column.  That is, the column has become too narrow to see "100%", and I
   have to correct it by manually dragging the window wider.  This happens
   every time.  It doesn't matter that I dragged it wider earlier; it has
   auto-adjusted itself correctly to every change except that new "100%"
   appearing.
*  I am not allowed to nationalize By shares from other people even though
   I have 60%.
*  The program does allow people with 30% or more in a newly formed company
   (which has not operated) to sell down to the president's certificate (or
   at least their holding lights up to be selected, I didn't try to do it).
*  When somebody does sell By, I'm not allowed to buy them then either, so
   apparently the program still imposes a 60% holding limit in 1835.

The last three points are all major errors, and the last is enough of a big
deal for me that I'm only continuing the game to see how well, or badly, the
program handles Pr formation.

In OR6, now that Ba/Wt/He have all formed, By uses the Pfalz to lay a
tile in Ludwigshafen/Mannheim.  This produces a pop-up which says exactly:
   {0}m select a station on tile {1} for the {2} home base token
Aside from the fact that the obvious variables have failed to be put in,
this is an error.  HiG issued a clarification saying that the Ba home token,
unlike all others in the game, is not placed until Ba's first turn.
(Presumably if the tile does not get laid then or earlier, then when it is,
whoever lays the tile will decide which station belongs to Ba, but that is
unlikely enough to be an unimportant case.)

After I place He's last token in Koln, I'm still asked if I want to place
one using the Pfalz power (so it isn't detecting that you have no tokens).

Next stock round I discover another bug:
*  Buying the final 20% certificate of Ba/Wt/He is correctly done as one
   purchase (though the player doesn't find that out until you click on it,
   if he didn't know), but the program counts it as two certificates, so a
   player who already has 14 is not allowed to do it.  He can click on it
   but is then told no.

Finally, M2 buys the first 4 train.  The 2 trains disappear and he is forced
to discard a train of his choosing, but he is NOT offered a chance to form
the Pr.

At this point I quit.

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

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

I consider 1835 "almost playable" by now. Main things left to do:
- PR operation in its first OR (yes/no)
- closing rules of some privates (a correction mode to close a private might
come in handy)
- specific rules of some of the already included variants
- perhaps more variants

Erik

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Saturday 17 April 2010 17:04
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

Aliza,
this reminds me of the suggested changes of the implemention levels as 
discussed some time ago for the next release. It seems to come close to what

you have in mind.

So far the opinions for the individual 18xx were:

1825: D
1830: B/A
1835: D
1851: B
1856: 
1870: D
1889: B
18AL: B
18EU: C/B

With A=mature, B=fully playable, C=almost playable, D=experimental.
(See definitions below)

There has not been any comment on the level of 1856 with respect to the 
scaling above. And keep in mind that even if the individual 18xx might be 
stable, Rails itself is still not feature complete, thus even stable 18xx 
might be impacted from time to time. 

Stefan

A) Mature
- Several independent plays until the end reported
- Full implementation of the ruleset
- All possible moves are available
- No illegal move possible (except tile and token lays, revenue calculation)
=> Serious ftf play possible
=> pbem play possible

B) Fully Playable
- Full implementation of the ruleset
- All possible moves are available
- Might still allow a few illegal moves (in addition to tile and token lays,
revenue calculation)
=> Serious ftf play possible, but bugs are possible
=> use with caution for pbem play, version incompatibilities possible

C) Almost Playable
- Nearly complete implementation of the ruleset
- Not all possible moves are available
- Illegal moves are possible
=> Serious testing possible, do not expect to complete a game
=> not recommended for pbem play

D) Experimental
- Rules and components are incomplete
=> Some testing possible



On Friday 16 April 2010 22:25:41 Aliza Panitz wrote:
> Is there going to be a Rails release with this bug fix in it? (We're
> trying to decide how/whether to continue the game this bug was
> reported on...)
>
> 1856 has been marked as "fully supported" since Rails 1.0.7 and I'm
> still struggling to complete PbEM games I started in November...
> perhaps there should be another game status, "first release" or
> "playtesting needed" or something, to denote games that are mostly
> complete but for which there has been no extensive playtesting.
>
>  - Aliza
>
> On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
> > Never mind, I could reproduce the problem as described below, and have
> > fixed it.
> > Can’t upload it now (SVN seems down) so that will be done tomorrow.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Friday 26 March 2010 00:00
> > To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
> >
> > Ah, you mean that sales of 15% and 5% have added up?
> > If that is what has happened, I think I know what has caused this.
> > A saved file would of course help a lot...
> >
> > Erik.
> >
> >
> >
> > -----Original Message-----
> > From: Joshua Gottesman [mailto:jos...@gm...]
> > Sent: Thursday 25 March 2010 22:56
> > To: Aliza Panitz
> > Cc: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
> >
> > Yeah, I didn't even notice that.  I just expected it to keep the price
> > the same.  I suspect what happened is it counted your 15% and held the
> > 1/2 share and then combined that with my 1/2 share for another price
> > drop.  Which is incorrect.
> >
> > On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...>
> >
> > wrote:
> >> Rails 1.2.2 bug:
> >>
> >> Selling a single 5% share of the CGR to the pool should not have
> >> changed the stock
> >> price.
> >>
> >> To quote the rules:
> >>
> >> ==============
> >> The share value tokens move:
> >>
> >> Down one row for each full 10% share sold either during a stock round
> >> or during a forced sale by a company president. The sale of a single
> >> 5% share does not affect the share value token. Sales of multiple 5%
> >> shares move the share value token
> >> ==============
> >>
> >> To quote the game report:
> >> ]  Joshua sells a 5% share of CGR to Pool for $90.
> >> ] CGR price goes from $90(E2) to $80(E3).
> >>
> >>
> >> I'll file an official bug later if nobody else gets to it first.
> >>
> >>  - Aliza
> >>
> >> 2010/3/25 Joshua Gottesman <jos...@gm...>:
> >> - Hide quoted text -
> >>
> >>> ==================
> >>> Start of Stock Round 6
> >>> ==================
> >>> Aliza has the Priority Deal
> >>>
> >>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
> >>> CGR price goes from $100(E1) to $90(E2).
> >>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
> >>> Joshua sells a 5% share of CGR to Pool for $90.
> >>> CGR price goes from $90(E2) to $80(E3).
> >>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank
> >
> >
-------------------------------------------------------------------------
> >--- --
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> >
-------------------------------------------------------------------------
> >--- --
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> >
-------------------------------------------------------------------------
> >----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>--- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

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

Stefan -

Let's go ahead and update the playability scale with your proposal. If
it needs future tweaking, we can do that.

My best guess for '56 is probably almost a B, but still mostly a C.
It's almost fully playable but not quite.  Aliza and others are still
hitting far too many issues to consider it guaranteed to be able to
play a complete game without issue.

---Brett.



On Sat, Apr 17, 2010 at 8:03 AM, Stefan Frey <ste...@we...> wrote:
> Aliza,
> this reminds me of the suggested changes of the implemention levels as
> discussed some time ago for the next release. It seems to come close to what
> you have in mind.
>
> So far the opinions for the individual 18xx were:
>
> 1825: D
> 1830: B/A
> 1835: D
> 1851: B
> 1856:
> 1870: D
> 1889: B
> 18AL: B
> 18EU: C/B
>
> With A=mature, B=fully playable, C=almost playable, D=experimental.
> (See definitions below)
>
> There has not been any comment on the level of 1856 with respect to the
> scaling above. And keep in mind that even if the individual 18xx might be
> stable, Rails itself is still not feature complete, thus even stable 18xx
> might be impacted from time to time.
>
> Stefan
>
> A) Mature
> - Several independent plays until the end reported
> - Full implementation of the ruleset
> - All possible moves are available
> - No illegal move possible (except tile and token lays, revenue calculation)
> => Serious ftf play possible
> => pbem play possible
>
> B) Fully Playable
> - Full implementation of the ruleset
> - All possible moves are available
> - Might still allow a few illegal moves (in addition to tile and token lays,
> revenue calculation)
> => Serious ftf play possible, but bugs are possible
> => use with caution for pbem play, version incompatibilities possible
>
> C) Almost Playable
> - Nearly complete implementation of the ruleset
> - Not all possible moves are available
> - Illegal moves are possible
> => Serious testing possible, do not expect to complete a game
> => not recommended for pbem play
>
> D) Experimental
> - Rules and components are incomplete
> => Some testing possible
>
>
>
> On Friday 16 April 2010 22:25:41 Aliza Panitz wrote:
>> Is there going to be a Rails release with this bug fix in it? (We're
>> trying to decide how/whether to continue the game this bug was
>> reported on...)
>>
>> 1856 has been marked as "fully supported" since Rails 1.0.7 and I'm
>> still struggling to complete PbEM games I started in November...
>> perhaps there should be another game status, "first release" or
>> "playtesting needed" or something, to denote games that are mostly
>> complete but for which there has been no extensive playtesting.
>>
>>  - Aliza
>>
>> On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
>> > Never mind, I could reproduce the problem as described below, and have
>> > fixed it.
>> > Can’t upload it now (SVN seems down) so that will be done tomorrow.
>> >
>> > Erik.
>> >
>> > -----Original Message-----
>> > From: Erik Vos [mailto:eri...@xs...]
>> > Sent: Friday 26 March 2010 00:00
>> > To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
>> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>> >
>> > Ah, you mean that sales of 15% and 5% have added up?
>> > If that is what has happened, I think I know what has caused this.
>> > A saved file would of course help a lot...
>> >
>> > Erik.
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Joshua Gottesman [mailto:jos...@gm...]
>> > Sent: Thursday 25 March 2010 22:56
>> > To: Aliza Panitz
>> > Cc: Development list for Rails: an 18xx game
>> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>> >
>> > Yeah, I didn't even notice that.  I just expected it to keep the price
>> > the same.  I suspect what happened is it counted your 15% and held the
>> > 1/2 share and then combined that with my 1/2 share for another price
>> > drop.  Which is incorrect.
>> >
>> > On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...>
>> >
>> > wrote:
>> >> Rails 1.2.2 bug:
>> >>
>> >> Selling a single 5% share of the CGR to the pool should not have
>> >> changed the stock
>> >> price.
>> >>
>> >> To quote the rules:
>> >>
>> >> ==============
>> >> The share value tokens move:
>> >>
>> >> Down one row for each full 10% share sold either during a stock round
>> >> or during a forced sale by a company president. The sale of a single
>> >> 5% share does not affect the share value token. Sales of multiple 5%
>> >> shares move the share value token
>> >> ==============
>> >>
>> >> To quote the game report:
>> >> ]  Joshua sells a 5% share of CGR to Pool for $90.
>> >> ] CGR price goes from $90(E2) to $80(E3).
>> >>
>> >>
>> >> I'll file an official bug later if nobody else gets to it first.
>> >>
>> >>  - Aliza
>> >>
>> >> 2010/3/25 Joshua Gottesman <jos...@gm...>:
>> >> - Hide quoted text -
>> >>
>> >>> ==================
>> >>> Start of Stock Round 6
>> >>> ==================
>> >>> Aliza has the Priority Deal
>> >>>
>> >>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
>> >>> CGR price goes from $100(E1) to $90(E2).
>> >>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
>> >>> Joshua sells a 5% share of CGR to Pool for $90.
>> >>> CGR price goes from $90(E2) to $80(E3).
>> >>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank
>> >
>> > -------------------------------------------------------------------------
>> >--- --
>> > Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> > -------------------------------------------------------------------------
>> >--- --
>> > Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> >
>> > -------------------------------------------------------------------------
>> >----- Download Intel&#174; Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>>--- Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

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

Aliza,
this reminds me of the suggested changes of the implemention levels as 
discussed some time ago for the next release. It seems to come close to what 
you have in mind.

So far the opinions for the individual 18xx were:

1825: D
1830: B/A
1835: D
1851: B
1856: 
1870: D
1889: B
18AL: B
18EU: C/B

With A=mature, B=fully playable, C=almost playable, D=experimental.
(See definitions below)

There has not been any comment on the level of 1856 with respect to the 
scaling above. And keep in mind that even if the individual 18xx might be 
stable, Rails itself is still not feature complete, thus even stable 18xx 
might be impacted from time to time. 

Stefan

A) Mature
- Several independent plays until the end reported
- Full implementation of the ruleset
- All possible moves are available
- No illegal move possible (except tile and token lays, revenue calculation)
=> Serious ftf play possible
=> pbem play possible

B) Fully Playable
- Full implementation of the ruleset
- All possible moves are available
- Might still allow a few illegal moves (in addition to tile and token lays,
revenue calculation)
=> Serious ftf play possible, but bugs are possible
=> use with caution for pbem play, version incompatibilities possible

C) Almost Playable
- Nearly complete implementation of the ruleset
- Not all possible moves are available
- Illegal moves are possible
=> Serious testing possible, do not expect to complete a game
=> not recommended for pbem play

D) Experimental
- Rules and components are incomplete
=> Some testing possible



On Friday 16 April 2010 22:25:41 Aliza Panitz wrote:
> Is there going to be a Rails release with this bug fix in it? (We're
> trying to decide how/whether to continue the game this bug was
> reported on...)
>
> 1856 has been marked as "fully supported" since Rails 1.0.7 and I'm
> still struggling to complete PbEM games I started in November...
> perhaps there should be another game status, "first release" or
> "playtesting needed" or something, to denote games that are mostly
> complete but for which there has been no extensive playtesting.
>
>  - Aliza
>
> On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
> > Never mind, I could reproduce the problem as described below, and have
> > fixed it.
> > Can’t upload it now (SVN seems down) so that will be done tomorrow.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Friday 26 March 2010 00:00
> > To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
> >
> > Ah, you mean that sales of 15% and 5% have added up?
> > If that is what has happened, I think I know what has caused this.
> > A saved file would of course help a lot...
> >
> > Erik.
> >
> >
> >
> > -----Original Message-----
> > From: Joshua Gottesman [mailto:jos...@gm...]
> > Sent: Thursday 25 March 2010 22:56
> > To: Aliza Panitz
> > Cc: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
> >
> > Yeah, I didn't even notice that.  I just expected it to keep the price
> > the same.  I suspect what happened is it counted your 15% and held the
> > 1/2 share and then combined that with my 1/2 share for another price
> > drop.  Which is incorrect.
> >
> > On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...>
> >
> > wrote:
> >> Rails 1.2.2 bug:
> >>
> >> Selling a single 5% share of the CGR to the pool should not have
> >> changed the stock
> >> price.
> >>
> >> To quote the rules:
> >>
> >> ==============
> >> The share value tokens move:
> >>
> >> Down one row for each full 10% share sold either during a stock round
> >> or during a forced sale by a company president. The sale of a single
> >> 5% share does not affect the share value token. Sales of multiple 5%
> >> shares move the share value token
> >> ==============
> >>
> >> To quote the game report:
> >> ]  Joshua sells a 5% share of CGR to Pool for $90.
> >> ] CGR price goes from $90(E2) to $80(E3).
> >>
> >>
> >> I'll file an official bug later if nobody else gets to it first.
> >>
> >>  - Aliza
> >>
> >> 2010/3/25 Joshua Gottesman <jos...@gm...>:
> >> - Hide quoted text -
> >>
> >>> ==================
> >>> Start of Stock Round 6
> >>> ==================
> >>> Aliza has the Priority Deal
> >>>
> >>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
> >>> CGR price goes from $100(E1) to $90(E2).
> >>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
> >>> Joshua sells a 5% share of CGR to Pool for $90.
> >>> CGR price goes from $90(E2) to $80(E3).
> >>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank
> >
> > -------------------------------------------------------------------------
> >--- --
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > -------------------------------------------------------------------------
> >--- --
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > -------------------------------------------------------------------------
> >----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>--- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

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

Brett:
a good question: There are a few pieces missing for my stuff, but it is not 
that much. We had a ftf 1889 yesterday on Rails and both revenue calculation 
and route awareness worked without a problem, but 1889 does not have a very 
demanding network structure.lo

From my side a release should be possible in one week's time.

Map Correction:

* Any kind of tile up- and downgrades are possible, but tokens are not 
adjusted to reflect the changed number of stations or slots.
For this I have to wait for Erik to solve the current issues before I 
link to his code or add my extensions for downgrades.

* No token corrections so far, this will have to wait for a future release.

Revenue Calculation:

* Works for standard trains for 18xx without special revenue types (tested for 
1830 and 1889 so far).

* A game option has to be added to deactivate revenue calculation throughout 
the game. This would also deactivate revenue calculation for those games 
which are not supported (or tested) so far.

Route Awareness:

* The highlighting of available hexes can be wrong on complicated networks. 
(It does not impact revenue calculation however, as they use different type 
of iterators.)

All of the three extensions above are loosely connected to the main code, thus 
it would be easy to deactivate them if they are not ready for shippment.
And they are not rule enforcing, thus they do not change the strategy space. 
You can still lay the tiles as before and the calculated revenue is only a 
suggestion for the revenue step.

Stefan

On Saturday 17 April 2010 00:35:45 brett lentz wrote:
> There will be. I think the question you'd like to ask is, "When will
> the next release be?"
>
> The answer to that question is... as soon as somebody feels that
> there's a sufficient level of stability in the recent work to request
> one. :-)
>
> Erik/Stefan - What do you guys think?  I know Stefan's been mostly
> working on the route calculation stuff. Will that impact a new
> release?
>
> ---Brett.
>
> On Fri, Apr 16, 2010 at 1:25 PM, Aliza Panitz <ali...@gm...> 
wrote:
> > Is there going to be a Rails release with this bug fix in it? (We're
> > trying to decide how/whether to continue the game this bug was
> > reported on...)
> >
> > 1856 has been marked as "fully supported" since Rails 1.0.7 and I'm
> > still struggling to complete PbEM games I started in November...
> > perhaps there should be another game status, "first release" or
> > "playtesting needed" or something, to denote games that are mostly
> > complete but for which there has been no extensive playtesting.
> >
> >  - Aliza
> >
> > On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
> >> Never mind, I could reproduce the problem as described below, and have
> >> fixed it.
> >> Can’t upload it now (SVN seems down) so that will be done tomorrow.
> >>
> >> Erik.
> >>
> >> -----Original Message-----
> >> From: Erik Vos [mailto:eri...@xs...]
> >> Sent: Friday 26 March 2010 00:00
> >> To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
> >> Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
> >>
> >> Ah, you mean that sales of 15% and 5% have added up?
> >> If that is what has happened, I think I know what has caused this.
> >> A saved file would of course help a lot...
> >>
> >> Erik.
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Joshua Gottesman [mailto:jos...@gm...]
> >> Sent: Thursday 25 March 2010 22:56
> >> To: Aliza Panitz
> >> Cc: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
> >>
> >> Yeah, I didn't even notice that.  I just expected it to keep the price
> >> the same.  I suspect what happened is it counted your 15% and held the
> >> 1/2 share and then combined that with my 1/2 share for another price
> >> drop.  Which is incorrect.
> >>
> >> On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...>
> >>
> >> wrote:
> >>> Rails 1.2.2 bug:
> >>>
> >>> Selling a single 5% share of the CGR to the pool should not have
> >>> changed the stock
> >>> price.
> >>>
> >>> To quote the rules:
> >>>
> >>> ==============
> >>> The share value tokens move:
> >>>
> >>> Down one row for each full 10% share sold either during a stock round
> >>> or during a forced sale by a company president. The sale of a single
> >>> 5% share does not affect the share value token. Sales of multiple 5%
> >>> shares move the share value token
> >>> ==============
> >>>
> >>> To quote the game report:
> >>> ]  Joshua sells a 5% share of CGR to Pool for $90.
> >>> ] CGR price goes from $90(E2) to $80(E3).
> >>>
> >>>
> >>> I'll file an official bug later if nobody else gets to it first.
> >>>
> >>>  - Aliza
> >>>
> >>> 2010/3/25 Joshua Gottesman <jos...@gm...>:
> >>> - Hide quoted text -
> >>>
> >>>> ==================
> >>>> Start of Stock Round 6
> >>>> ==================
> >>>> Aliza has the Priority Deal
> >>>>
> >>>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
> >>>> CGR price goes from $100(E1) to $90(E2).
> >>>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
> >>>> Joshua sells a 5% share of CGR to Pool for $90.
> >>>> CGR price goes from $90(E2) to $80(E3).
> >>>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank
> >>
> >> ------------------------------------------------------------------------
> >>---- --
> >> Download Intel&#174; Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >>
> >> ------------------------------------------------------------------------
> >>---- --
> >> Download Intel&#174; Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >>
> >> ------------------------------------------------------------------------
> >>------ Download Intel&#174; Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>--- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Automatic route calculation

[alexti <al...@sh...>]

Hi Stefan,

On Fri, 16 Apr 2010 10:36:14 -0600, Stefan Frey <ste...@we...> wrote:

> Hi Alex,
> I do not have much time now, but I will try to give some answers below.
>
> On Wednesday 14 April 2010 08:00:19 alexti wrote:
>> Hi Stefan,
>>
>> Don't worry about embarrassing errors! I have one somewhere and I don't
>> even know where :) - I don't know why my algorithm doesn't find the
>> optimal solution you've mentioned - it's supposed to, it's completely
>> brute force and it should check every combination, but apparently it
>> doesn't. I suspect I have a bug in my new 2-phased code where I  
>> determine
>> which segments connecting cities are mutually exclusive.
>
> My guess for a potential reason and my main problem how efficient your  
> 2-phase
> approach is: Does you really create all possible paths between two  
> stations
> in the first phase? This could be a quite large set, I assume, or do you  
> rule
> some out, because they appear to be not optimal? And if I follow your
> approach correctly, you need a two dimensional boolean array of that  
> squared
> size, to indicate which potential routes share at least one edge.
Yes, I create all possible direct routes (not visiting anything else of  
value) for each city pair.
The number of those doesn't seem to be very large. Typically, you will  
rarely see more than 50 city/towns on the map, so that's 2500 pairs and  
it's hard to imagine that there would be more than 4 routes per pair on  
average, so 10000 seems like a reasonable upper bound. 2D-boolean array  
would take 10^4*10^4/8 ~ 10Mb which is not a big issue. In practice I  
don't actually use 2-D boolean array - instead for each segment I keep a  
list of segment ids it shares edges with, but I suspect that from the  
performance point of view 2-D boolean array is a better option. I'm going  
to try it when I get time. It's probably necessary two have 2 such arrays  
- one for shared edges and another for shared vertices (to allow quick  
check for the single-train route).

>
> I really like the idea, but I would like to know the dimension of that  
> array
> first. The really neat thing is that it can be combined with revenue
> prediction and would allow really fast solutions for even more complex  
> case,
> when we have considered so far.
Yes, those approaches can be combined perfectly.

>> I wonder, how do you plan to do the "best route estimates" in general.
>> When the various train and bonus rules are added ("free" towns, express
>> trains, doubling trains, East-West runs, bonuses for connecting pairs of
>> cities etc...) evaluating what should be in the optimal route is going  
>> to
>> be rather complex. It's also important to figure out how to quickly find
>> pretty good set of routes, thus cutting off a lot of the search tree.
>
> A very condense answer here:
>
> A) The revenue prediction at each point of the search tracks divides the  
> set
> of trains into two subsets, which I call past and future trains. The  
> same is
> true for the current train, which can be separated into a past  
> (half-)train
> and a future (half-)train as well: Assume it is a 10 train, which has  
> visited
> a 4 stations already. That is a 4 past train and a 6 future train.
>
> B) Past trains are evaluated with revenue function like you do. For the  
> future
> trains there exist two lists (one for cities, one for towns) of the  
> maximum
> amount of revenue you can generate for a given length. Those lists are  
> the
> cumulated revenue of the stations sorted by revenue potential. For the
> current train there is the additional cap that the combination of the  
> past
> value and the future value of the half train cannot exceed the future  
> value
> of the full train length.
>
> C) During preparation I even cut train lengths to the maximum amount of
> stations which are available to the railroad. Thus a Diesel is in fact a  
> nb
> of stations length train and if a railroad reaches 3 cities and 10 towns  
> and
> runs a 5+5 train, it gets converted to a 3+7.
> That helps to determine that I can terminate a running train, because  
> there
> are no more stations out to visit.
>
> D) Trains are characterized by 5 attributes so far: cities, towns,
> ignoreTowns, multiplyCities, multiplyTowns.
>
> This allows to define the train types you suggested above.
> express = ignoreTowns set to true
> free towns = set towns for each train to the maximum of towns the  
> railroad has
> doubling trains = use the multiples
> The prediction function uses the multiplier and the train lengths similar
> to the evaluation function.
>
> E) Bonuses
> I have not incorporated any kind of bonus so far. My current idea is to  
> define
> bonuses by combinations of vertexes which have to be visited to get the
> bonus.
>
> The bonus itself can be revenue increase (or even decrease think about  
> the
> elbe crossing in HH) or change of the cities or town multipliers.
> Sometimes the bonuses are mutually exclusive or only available to one  
> train
> instead of all of them. I would like to make that definition as generic  
> as
> possible to capture most of the types.
>
> For prediction the thing is simple: In general I assume that a future  
> train
> will score each and every bonus, unless it is already used by a past  
> train
> (and it was a bonus which is only available once). By this assumption I  
> am on
> the safe side.
Ok, I got the idea. It makes sense to me. Efficiency of it will probably  
vary depending on the game - those that have a lot of "free" towns, or  
those that have massive bonuses would make it harder to cut down the  
search tree quickly.

And I agree with your approach to bonuses - that's what I'm doing too.  
Defining (and applying) them is not hard.

> F) Finding a good route quickly
> One optimization I do:
> I sort all vertexes by revenue potential and by this at each junction the
> train moves to the vertex with the best revenue potential and it starts  
> at
> the most valuable start vertex.
That's a good idea. I suppose if we combine it with 2-phased approach we  
could just look at the most valuable cities and try to find a route  
linking them which should be very quick, then we'll have a good chance  
that most of the rest of the search tree will be cut off.

I also think that with 2-phased approach it's probably worth removing  
unreachable part of the graph (due to station blocking). In my experience  
(of some cut-throat games) it's very typical that companies are rather  
restricted in what they can reach :)


Thanks,
Alex.



> The other thing is that the search is depth-first, thus each train will  
> try to
> run as long as possible. The latter combinations are usually those which  
> are
> shorter. From my experience the best solution is always found in the  
> first
> 5-10% of the running time (if it runs without revenue predicition).
>
> But one could easily create degenerated networks, that will make the
> prediction completely worthless: Consider that each station is  
> surrounded by
> a complex network of tracks, but each station is not linked to any  
> other. In
> that case the best run will be zero, but it will take a lot of time to  
> find
> this out. In that case your algorithm will excel.
> But how often do find that case in 18xx?
>
> I hope that gives some more insight.
>
> Stefan
>
>>
>> The times start to look promising, even the complete run finishing in  
>> 1-2
>> minutes is pretty good. With one-phased algorithm it was taking ~40
>> seconds on my machine to do complete search.
>>
>> Thanks,
>> Alex.
>>
>>
>> On Tue, 13 Apr 2010 17:01:37 -0600, Stefan Frey (web.de)
>>
>> <ste...@we...> wrote:
>> > Hi Alex and all others...
>> > ... discussing revenue calculation. It seems to spur a lot of  
>> interest.
>> >
>> > Sorry for the long post (if one includes the text document), but I  
>> try to
>> > answer most of the asked and some of the not-yet asked questions.
>> > And it seems that the algorithms already improve from the fruitful
>> > discussion.
>> >
>> > Some talk about the concepts are in the attached text document, that  
>> was
>> > easier to edit.
>> >
>> > This is the good thing of commit early and often. One of its
>> > disadvantages are
>> > the embarrassing errors in the early releases. I list those at the end
>> > of the
>> > attachment and hopefully it will clarify some of the problems you ran
>> > into.
>> >
>> > Good news first:
>> >
>> > * Running Times
>> > After hunting them down and adding a new concept (the revenue  
>> prediction
>> > - see
>> > attachment) evaluation time is now down to 1-2 seconds for a 8 and 10
>> > train
>> > on the A scenario on my laptop. Without revenue prediction it runs for
>> > 1-2
>> > minutes. Both runs have identical results.
>> >
>> > * Optimal Solution (?)
>> > The other thing is that my implementation suggests a (slightly)
>> > different path
>> > than Alex' which results in an increase of revenue.
>> > The change is that the 8 train does not have the 10 - 30 - 30 (
>> > that is Alexandria and Baton Rouge in 1870, the right bottom in Alex
>> > graph -
>> > it is rotated) in the end, but the 10 - 30 - 50 (that is Austin and
>> > SouthWest
>> > on the map, the right top in Alex graph). Thus it runs for 20 more.
>> >
>> > It now pays off that we have independent algorithms running, that can
>> > find
>> > flaws in each others (like you did for mine).
>> >
>> > Stefan
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Automatic route calculation

[alexti <al...@sh...>]

On Fri, 16 Apr 2010 15:32:20 -0600, Aliza Panitz <ali...@gm...>  
wrote:

> On Sun, Apr 11, 2010 at 9:58 PM, alexti <al...@sh...> wrote:
>> The first
>> graph (let's call it primary graph) is built from the tiles and
>> essentially follows one tile - 7 vertices principle (I've described this
>> approach before and after some discussion with Stefan we've concluded  
>> that
>> it's identical to the approach he had in mind). Essentially, one vertex  
>> is
>> in the center of the tile and there are 6 vertices, one per tile edge.
>
> What about double-dit and double-O cities (as well as more complex
> tiles that have three disjoint scoring locations...)
double-dit and double-O cities are 4-vertex 2-edge tiles (center vertex is  
not used), so they're easy to describe

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

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

There will be. I think the question you'd like to ask is, "When will
the next release be?"

The answer to that question is... as soon as somebody feels that
there's a sufficient level of stability in the recent work to request
one. :-)

Erik/Stefan - What do you guys think?  I know Stefan's been mostly
working on the route calculation stuff. Will that impact a new
release?

---Brett.


On Fri, Apr 16, 2010 at 1:25 PM, Aliza Panitz <ali...@gm...> wrote:
> Is there going to be a Rails release with this bug fix in it? (We're
> trying to decide how/whether to continue the game this bug was
> reported on...)
>
> 1856 has been marked as "fully supported" since Rails 1.0.7 and I'm
> still struggling to complete PbEM games I started in November...
> perhaps there should be another game status, "first release" or
> "playtesting needed" or something, to denote games that are mostly
> complete but for which there has been no extensive playtesting.
>
>  - Aliza
>
> On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
>> Never mind, I could reproduce the problem as described below, and have fixed
>> it.
>> Can’t upload it now (SVN seems down) so that will be done tomorrow.
>>
>> Erik.
>>
>> -----Original Message-----
>> From: Erik Vos [mailto:eri...@xs...]
>> Sent: Friday 26 March 2010 00:00
>> To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
>> Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>>
>> Ah, you mean that sales of 15% and 5% have added up?
>> If that is what has happened, I think I know what has caused this.
>> A saved file would of course help a lot...
>>
>> Erik.
>>
>>
>>
>> -----Original Message-----
>> From: Joshua Gottesman [mailto:jos...@gm...]
>> Sent: Thursday 25 March 2010 22:56
>> To: Aliza Panitz
>> Cc: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>>
>> Yeah, I didn't even notice that.  I just expected it to keep the price
>> the same.  I suspect what happened is it counted your 15% and held the
>> 1/2 share and then combined that with my 1/2 share for another price
>> drop.  Which is incorrect.
>>
>> On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...>
>> wrote:
>>> Rails 1.2.2 bug:
>>>
>>> Selling a single 5% share of the CGR to the pool should not have
>>> changed the stock
>>> price.
>>>
>>> To quote the rules:
>>>
>>> ==============
>>> The share value tokens move:
>>>
>>> Down one row for each full 10% share sold either during a stock round
>>> or during a forced sale by a company president. The sale of a single
>>> 5% share does not affect the share value token. Sales of multiple 5%
>>> shares move the share value token
>>> ==============
>>>
>>> To quote the game report:
>>> ]  Joshua sells a 5% share of CGR to Pool for $90.
>>> ] CGR price goes from $90(E2) to $80(E3).
>>>
>>>
>>> I'll file an official bug later if nobody else gets to it first.
>>>
>>>  - Aliza
>>>
>>> 2010/3/25 Joshua Gottesman <jos...@gm...>:
>>> - Hide quoted text -
>>>> ==================
>>>> Start of Stock Round 6
>>>> ==================
>>>> Aliza has the Priority Deal
>>>>
>>>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
>>>> CGR price goes from $100(E1) to $90(E2).
>>>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
>>>> Joshua sells a 5% share of CGR to Pool for $90.
>>>> CGR price goes from $90(E2) to $80(E3).
>>>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank
>>>>
>>>
>>
>> ----------------------------------------------------------------------------
>> --
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ----------------------------------------------------------------------------
>> --
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Automatic route calculation

[Aliza P. <ali...@gm...>]

On Sun, Apr 11, 2010 at 9:58 PM, alexti <al...@sh...> wrote:
> The first
> graph (let's call it primary graph) is built from the tiles and
> essentially follows one tile - 7 vertices principle (I've described this
> approach before and after some discussion with Stefan we've concluded that
> it's identical to the approach he had in mind). Essentially, one vertex is
> in the center of the tile and there are 6 vertices, one per tile edge.

What about double-dit and double-O cities (as well as more complex
tiles that have three disjoint scoring locations...)

Re: [Rails-devel] Junit reports broken test cases

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

These two files reflect identical game positions, both having Erie green and
C&A brown. 
Indeed one brown OO tile lay let the Erie token jump, but perhaps even worse
is that several wrong brown tile lays are allowed.
That wasn't so in the past, so I wonder what might have broken that logic.

Anyway, work to do. This was one of the real hard parts to get right...

But before I can even think of sorting this out, I must get rid of all that
DEBUG logging that Stefan has added.
Fortunately, there is a simple way to do that.
HINT FOR EVERYONE: if you can, add the following line to your version of
my.properties:
log4j.logger.rails.algorithms=INFO

Erik. 

-----Original Message-----
From: ste...@we... [mailto:ste...@we...] 
Sent: Friday 16 April 2010 18:00
To: Development list for Rails: an 18xx game
Cc: Erik Vos
Subject: Re: Junit reports broken test cases

Erik:
I did a quick test game for 1830 to verify the revenue calculation and it 
seems that the token lay mechanism is also broken for the OO-tiles. 

And I assume you have not changed the definition of those.

I have attached two example files:
A) Erie tile lay
If you have NYC lay the brown tile on the Erie base, the Erie token will be 
beamed to the other city.

B) Token lay on the C&A hex
If you have the NYC lay the brown tile on the C&A hex, then it replaces the 
PRR token on the wrong station. In addition the route awareness graph thinks

that the station on the C&A hex is tokened out, thus it seems that the 
graphical representation and the internal ones are swapped.

In both cases playing around with undo can make things even worse.

Another issue arose, which might be connected: If I lay the NYC home base 
brown and undo that, then the revenue code assumes that NYC has no token 
anymore to start with.

Stefan

PS: to the list as it impacts the testing of other parts of rails as well 
(especially revenue calculation)

On Thursday 15 April 2010 23:02:27 Erik Vos wrote:
> Stefan,
>
> The problem was caused by the Toronto tile change, but remained hidden
> until I implemented reserved token space avoidance.
> Now that I think about it, I remember that at some point (probably just
> after the Toronto change) the CV token spot had moved to the NE side of
> Toronto. At that time I changed the CV home station number, which in
> hindsight was stupid: I should have changed (or rotated) the tile. I'm
> afraid the only way to fix the test cases is to replay the games, at least
> from the point of failure.
>
> Erik.
>
> -----Original Message-----
> From: ste...@we... [mailto:ste...@we...]
> Sent: Thursday 15 April 2010 22:32
> To: Erik Vos
> Subject: Re: Junit reports broken test cases
>
> The one thing I do not fully understand: I uploaded the Junit class after
> the
> 1.2.2 release: Thus the cases were constructed with the a version that is
> after that latest release and they worked at that time.
>
> You suspect that this is related to the change of Toronto tile, which was
> released with 1.2.  Thus one of your changes combined with the new Toronto
> tile works differently as with the old (NY - if I remember correctly?).
> That
>
> seems to be a pretty subtle problem. It also means that all 1856 plays
from
> before 1.2. are potentially suspect to this problem.
>
> Would it help to open the test cases under 1.2.2. and then save it there
> and
>
> then open with the current HEAD?
>
> Stefan
>
> On Thursday 15 April 2010 22:07:59 you wrote:
> > OK, I have uploaded the fix (and another few minor ones).
> >
> > I'm afraid that about all my 1856 saved files (including the ones I sent
> > you) are now invalid. I could fix it by reversing the city numbers in
the
> > new Toronto tile -56001, but that would invalidate any later saved
games,
> > so that might not be a very good idea. However, this now makes
regression
> > testing of 1856 rather difficult.
> >
> > Not sure if have sent you any 1835 saved files, but some of mine are
also
> > invalid now (for a different reason).
> >
> > Erik.
> >
> >
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Wednesday 14 April 2010 23:30
> > To: 'ste...@we...'
> > Subject: RE: Junit reports broken test cases
> >
> > It's about token laying on reserved city spots.
> >
> > The 18EU case was a bug, which I have fixed.
> >
> > In the 1856 case (at least the one that I could check) a GT token was
> > laid on the Toronto CV spot. This may be caused by the recent
replacement
> > of
>
> the
>
> > Toronto tile; I might have swapped the station numbers on that tile, and
>
> if
>
> > so, that would explain it.
> > If this is the explanation, all older 1856 saved games that have this
>
> token
>
> > lay are invalid and must be removed from the test set.
> >
> > In another test I'm hitting on problems with the 1835 PR formation,
which
> > suddenly does not work anymore for unclear reasons.
> > I will first sort that out before I upload any changes.
> >
> > Erik.
> >
> >
> >
> > -----Original Message-----
> > From: ste...@we... [mailto:ste...@we...]
> > Sent: Wednesday 14 April 2010 18:48
> > To: Erik Vos
> > Subject: Junit reports broken test cases
> >
> > Erik:
> > in your latest commit you changed something which broke several test
>
> games.
>
> > Most likely related to some lay tile or token activity.
> > Have attached the junit report.
> > Hope it helps to track it down, if it was not an intentional change.
> > Stefan

Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price

[Aliza P. <ali...@gm...>]

Is there going to be a Rails release with this bug fix in it? (We're
trying to decide how/whether to continue the game this bug was
reported on...)

1856 has been marked as "fully supported" since Rails 1.0.7 and I'm
still struggling to complete PbEM games I started in November...
perhaps there should be another game status, "first release" or
"playtesting needed" or something, to denote games that are mostly
complete but for which there has been no extensive playtesting.

 - Aliza

On Thu, Mar 25, 2010 at 4:27 PM, Erik Vos <eri...@xs...> wrote:
> Never mind, I could reproduce the problem as described below, and have fixed
> it.
> Can’t upload it now (SVN seems down) so that will be done tomorrow.
>
> Erik.
>
> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Friday 26 March 2010 00:00
> To: 'Development list for Rails: an 18xx game'; 'Aliza Panitz'
> Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>
> Ah, you mean that sales of 15% and 5% have added up?
> If that is what has happened, I think I know what has caused this.
> A saved file would of course help a lot...
>
> Erik.
>
>
>
> -----Original Message-----
> From: Joshua Gottesman [mailto:jos...@gm...]
> Sent: Thursday 25 March 2010 22:56
> To: Aliza Panitz
> Cc: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856: CGR Bug: selling 5% moves stock price
>
> Yeah, I didn't even notice that.  I just expected it to keep the price
> the same.  I suspect what happened is it counted your 15% and held the
> 1/2 share and then combined that with my 1/2 share for another price
> drop.  Which is incorrect.
>
> On Thu, Mar 25, 2010 at 2:54 PM, Aliza Panitz <ali...@gm...>
> wrote:
>> Rails 1.2.2 bug:
>>
>> Selling a single 5% share of the CGR to the pool should not have
>> changed the stock
>> price.
>>
>> To quote the rules:
>>
>> ==============
>> The share value tokens move:
>>
>> Down one row for each full 10% share sold either during a stock round
>> or during a forced sale by a company president. The sale of a single
>> 5% share does not affect the share value token. Sales of multiple 5%
>> shares move the share value token
>> ==============
>>
>> To quote the game report:
>> ]  Joshua sells a 5% share of CGR to Pool for $90.
>> ] CGR price goes from $90(E2) to $80(E3).
>>
>>
>> I'll file an official bug later if nobody else gets to it first.
>>
>>  - Aliza
>>
>> 2010/3/25 Joshua Gottesman <jos...@gm...>:
>> - Hide quoted text -
>>> ==================
>>> Start of Stock Round 6
>>> ==================
>>> Aliza has the Priority Deal
>>>
>>> Aliza sells 3 5% shares (15%) of CGR to Pool for $300.
>>> CGR price goes from $100(E1) to $90(E2).
>>> Aliza starts GT at $100 and pays $200 for 2 shares (20%) to Bank
>>> Joshua sells a 5% share of CGR to Pool for $90.
>>> CGR price goes from $90(E2) to $80(E3).
>>> Joshua starts TGB at $100 and pays $200 for 2 shares (20%) to Bank
>>>
>>
>
> ----------------------------------------------------------------------------
> --
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ----------------------------------------------------------------------------
> --
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1889 rules bug

[Justin R. <jus...@gm...>]

I think it should definitely be a configurable option when starting
the game so that people don't think it's a bug and start this thread
again and again. :)

On Fri, Apr 16, 2010 at 8:51 AM, Stefan Frey <ste...@we...> wrote:
> Hi Justin,
> you are right, that Rails does allow 70% for 1889 2 players.
>
> This is against the rules, but we use it frequently as a house rule for
> two player playing. And I was lazy to add a game option for that as you can
> still restrict yourself to 60% if you prefer the original rule.
>
> The current setup for 1889 here is identical to Rails 1830 implementation,
> which also allows 70% ownership for 2 player games, against the rules.
>
> However it is a little questionable if 1830 rules support 2 player games:
> Table 5 (money) does not contain 2 players, whereas table 3 (certificiate
> limit) does, but the rules also state that 2400 is distributed evenly between
> the two players.
>
> I could add a game option for 1889 (2p 60% vs. 70%), does anyone vote
> for a similar option for 1830?
>
> Stefan
>
>
> On Friday 16 April 2010 00:28:55 Justin Rebelo wrote:
>> Playing a 2-player game of 1889 right now and it is allowing me to
>> exceed 60% of a corporation which is in the white area of the stock
>> market.
>>
>> If more details are needed, I will provide whatever I am able to upon
>> request.
>>
>> ---------------------------------------------------------------------------
>>--- Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1889 rules bug

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

On Fri, Apr 16, 2010 at 8:51 AM, Stefan Frey <ste...@we...> wrote:
> I could add a game option for 1889 (2p 60% vs. 70%), does anyone vote
> for a similar option for 1830?
>
> Stefan


+1.

---Brett.

Re: [Rails-devel] Automatic route calculation

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

Hi Alex,
I do not have much time now, but I will try to give some answers below.

On Wednesday 14 April 2010 08:00:19 alexti wrote:
> Hi Stefan,
>
> Don't worry about embarrassing errors! I have one somewhere and I don't
> even know where :) - I don't know why my algorithm doesn't find the
> optimal solution you've mentioned - it's supposed to, it's completely
> brute force and it should check every combination, but apparently it
> doesn't. I suspect I have a bug in my new 2-phased code where I determine
> which segments connecting cities are mutually exclusive.

My guess for a potential reason and my main problem how efficient your 2-phase 
approach is: Does you really create all possible paths between two stations 
in the first phase? This could be a quite large set, I assume, or do you rule 
some out, because they appear to be not optimal? And if I follow your 
approach correctly, you need a two dimensional boolean array of that squared 
size, to indicate which potential routes share at least one edge.

I really like the idea, but I would like to know the dimension of that array 
first. The really neat thing is that it can be combined with revenue 
prediction and would allow really fast solutions for even more complex case, 
when we have considered so far.

>
> I wonder, how do you plan to do the "best route estimates" in general.
> When the various train and bonus rules are added ("free" towns, express
> trains, doubling trains, East-West runs, bonuses for connecting pairs of
> cities etc...) evaluating what should be in the optimal route is going to
> be rather complex. It's also important to figure out how to quickly find
> pretty good set of routes, thus cutting off a lot of the search tree.

A very condense answer here:

A) The revenue prediction at each point of the search tracks divides the set 
of trains into two subsets, which I call past and future trains. The same is 
true for the current train, which can be separated into a past (half-)train 
and a future (half-)train as well: Assume it is a 10 train, which has visited 
a 4 stations already. That is a 4 past train and a 6 future train.

B) Past trains are evaluated with revenue function like you do. For the future 
trains there exist two lists (one for cities, one for towns) of the maximum 
amount of revenue you can generate for a given length. Those lists are the 
cumulated revenue of the stations sorted by revenue potential. For the 
current train there is the additional cap that the combination of the past 
value and the future value of the half train cannot exceed the future value 
of the full train length.

C) During preparation I even cut train lengths to the maximum amount of 
stations which are available to the railroad. Thus a Diesel is in fact a nb 
of stations length train and if a railroad reaches 3 cities and 10 towns and 
runs a 5+5 train, it gets converted to a 3+7.
That helps to determine that I can terminate a running train, because there 
are no more stations out to visit.

D) Trains are characterized by 5 attributes so far: cities, towns,  
ignoreTowns, multiplyCities, multiplyTowns.

This allows to define the train types you suggested above. 
express = ignoreTowns set to true
free towns = set towns for each train to the maximum of towns the railroad has
doubling trains = use the multiples

The prediction function uses the multiplier and the train lengths similar
to the evaluation function.

E) Bonuses
I have not incorporated any kind of bonus so far. My current idea is to define 
bonuses by combinations of vertexes which have to be visited to get the 
bonus. 

The bonus itself can be revenue increase (or even decrease think about the 
elbe crossing in HH) or change of the cities or town multipliers. 
Sometimes the bonuses are mutually exclusive or only available to one train 
instead of all of them. I would like to make that definition as generic as 
possible to capture most of the types.

For prediction the thing is simple: In general I assume that a future train 
will score each and every bonus, unless it is already used by a past train 
(and it was a bonus which is only available once). By this assumption I am on 
the safe side.

F) Finding a good route quickly
One optimization I do:
I sort all vertexes by revenue potential and by this at each junction the 
train moves to the vertex with the best revenue potential and it starts at 
the most valuable start vertex.

The other thing is that the search is depth-first, thus each train will try to 
run as long as possible. The latter combinations are usually those which are 
shorter. From my experience the best solution is always found in the first 
5-10% of the running time (if it runs without revenue predicition).

But one could easily create degenerated networks, that will make the 
prediction completely worthless: Consider that each station is surrounded by 
a complex network of tracks, but each station is not linked to any other. In 
that case the best run will be zero, but it will take a lot of time to find 
this out. In that case your algorithm will excel.
But how often do find that case in 18xx?

I hope that gives some more insight. 

Stefan

>
> The times start to look promising, even the complete run finishing in 1-2
> minutes is pretty good. With one-phased algorithm it was taking ~40
> seconds on my machine to do complete search.
>
> Thanks,
> Alex.
>
>
> On Tue, 13 Apr 2010 17:01:37 -0600, Stefan Frey (web.de)
>
> <ste...@we...> wrote:
> > Hi Alex and all others...
> > ... discussing revenue calculation. It seems to spur a lot of interest.
> >
> > Sorry for the long post (if one includes the text document), but I try to
> > answer most of the asked and some of the not-yet asked questions.
> > And it seems that the algorithms already improve from the fruitful
> > discussion.
> >
> > Some talk about the concepts are in the attached text document, that was
> > easier to edit.
> >
> > This is the good thing of commit early and often. One of its
> > disadvantages are
> > the embarrassing errors in the early releases. I list those at the end
> > of the
> > attachment and hopefully it will clarify some of the problems you ran
> > into.
> >
> > Good news first:
> >
> > * Running Times
> > After hunting them down and adding a new concept (the revenue prediction
> > - see
> > attachment) evaluation time is now down to 1-2 seconds for a 8 and 10
> > train
> > on the A scenario on my laptop. Without revenue prediction it runs for
> > 1-2
> > minutes. Both runs have identical results.
> >
> > * Optimal Solution (?)
> > The other thing is that my implementation suggests a (slightly)
> > different path
> > than Alex' which results in an increase of revenue.
> > The change is that the 8 train does not have the 10 - 30 - 30 (
> > that is Alexandria and Baton Rouge in 1870, the right bottom in Alex
> > graph -
> > it is rotated) in the end, but the 10 - 30 - 50 (that is Austin and
> > SouthWest
> > on the map, the right top in Alex graph). Thus it runs for 20 more.
> >
> > It now pays off that we have independent algorithms running, that can
> > find
> > flaws in each others (like you did for mine).
> >
> > Stefan

Re: [Rails-devel] Junit reports broken test cases

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

Erik:
I did a quick test game for 1830 to verify the revenue calculation and it 
seems that the token lay mechanism is also broken for the OO-tiles. 

And I assume you have not changed the definition of those.

I have attached two example files:
A) Erie tile lay
If you have NYC lay the brown tile on the Erie base, the Erie token will be 
beamed to the other city.

B) Token lay on the C&A hex
If you have the NYC lay the brown tile on the C&A hex, then it replaces the 
PRR token on the wrong station. In addition the route awareness graph thinks 
that the station on the C&A hex is tokened out, thus it seems that the 
graphical representation and the internal ones are swapped.

In both cases playing around with undo can make things even worse.

Another issue arose, which might be connected: If I lay the NYC home base 
brown and undo that, then the revenue code assumes that NYC has no token 
anymore to start with.

Stefan

PS: to the list as it impacts the testing of other parts of rails as well 
(especially revenue calculation)

On Thursday 15 April 2010 23:02:27 Erik Vos wrote:
> Stefan,
>
> The problem was caused by the Toronto tile change, but remained hidden
> until I implemented reserved token space avoidance.
> Now that I think about it, I remember that at some point (probably just
> after the Toronto change) the CV token spot had moved to the NE side of
> Toronto. At that time I changed the CV home station number, which in
> hindsight was stupid: I should have changed (or rotated) the tile. I'm
> afraid the only way to fix the test cases is to replay the games, at least
> from the point of failure.
>
> Erik.
>
> -----Original Message-----
> From: ste...@we... [mailto:ste...@we...]
> Sent: Thursday 15 April 2010 22:32
> To: Erik Vos
> Subject: Re: Junit reports broken test cases
>
> The one thing I do not fully understand: I uploaded the Junit class after
> the
> 1.2.2 release: Thus the cases were constructed with the a version that is
> after that latest release and they worked at that time.
>
> You suspect that this is related to the change of Toronto tile, which was
> released with 1.2.  Thus one of your changes combined with the new Toronto
> tile works differently as with the old (NY - if I remember correctly?).
> That
>
> seems to be a pretty subtle problem. It also means that all 1856 plays from
> before 1.2. are potentially suspect to this problem.
>
> Would it help to open the test cases under 1.2.2. and then save it there
> and
>
> then open with the current HEAD?
>
> Stefan
>
> On Thursday 15 April 2010 22:07:59 you wrote:
> > OK, I have uploaded the fix (and another few minor ones).
> >
> > I'm afraid that about all my 1856 saved files (including the ones I sent
> > you) are now invalid. I could fix it by reversing the city numbers in the
> > new Toronto tile -56001, but that would invalidate any later saved games,
> > so that might not be a very good idea. However, this now makes regression
> > testing of 1856 rather difficult.
> >
> > Not sure if have sent you any 1835 saved files, but some of mine are also
> > invalid now (for a different reason).
> >
> > Erik.
> >
> >
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Wednesday 14 April 2010 23:30
> > To: 'ste...@we...'
> > Subject: RE: Junit reports broken test cases
> >
> > It's about token laying on reserved city spots.
> >
> > The 18EU case was a bug, which I have fixed.
> >
> > In the 1856 case (at least the one that I could check) a GT token was
> > laid on the Toronto CV spot. This may be caused by the recent replacement
> > of
>
> the
>
> > Toronto tile; I might have swapped the station numbers on that tile, and
>
> if
>
> > so, that would explain it.
> > If this is the explanation, all older 1856 saved games that have this
>
> token
>
> > lay are invalid and must be removed from the test set.
> >
> > In another test I'm hitting on problems with the 1835 PR formation, which
> > suddenly does not work anymore for unclear reasons.
> > I will first sort that out before I upload any changes.
> >
> > Erik.
> >
> >
> >
> > -----Original Message-----
> > From: ste...@we... [mailto:ste...@we...]
> > Sent: Wednesday 14 April 2010 18:48
> > To: Erik Vos
> > Subject: Junit reports broken test cases
> >
> > Erik:
> > in your latest commit you changed something which broke several test
>
> games.
>
> > Most likely related to some lay tile or token activity.
> > Have attached the junit report.
> > Hope it helps to track it down, if it was not an intentional change.
> > Stefan

Re: [Rails-devel] 1889 rules bug

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

Hi Justin,
you are right, that Rails does allow 70% for 1889 2 players.

This is against the rules, but we use it frequently as a house rule for 
two player playing. And I was lazy to add a game option for that as you can 
still restrict yourself to 60% if you prefer the original rule.

The current setup for 1889 here is identical to Rails 1830 implementation, 
which also allows 70% ownership for 2 player games, against the rules.

However it is a little questionable if 1830 rules support 2 player games: 
Table 5 (money) does not contain 2 players, whereas table 3 (certificiate 
limit) does, but the rules also state that 2400 is distributed evenly between 
the two players.

I could add a game option for 1889 (2p 60% vs. 70%), does anyone vote
for a similar option for 1830?

Stefan


On Friday 16 April 2010 00:28:55 Justin Rebelo wrote:
> Playing a 2-player game of 1889 right now and it is allowing me to
> exceed 60% of a corporation which is in the white area of the stock
> market.
>
> If more details are needed, I will provide whatever I am able to upon
> request.
>
> ---------------------------------------------------------------------------
>--- Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] 1889 rules bug

[Justin R. <jus...@gm...>]

Playing a 2-player game of 1889 right now and it is allowing me to
exceed 60% of a corporation which is in the white area of the stock
market.

If more details are needed, I will provide whatever I am able to upon request.

[Rails-devel] Automatic Revenue Update

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

I have checked in the code that feeds the revenue calculation automatically 
into  the ORPanel at the RevenueStep. The revenue calculator runs in a 
separate thread and updates the ORPanel (implements a RevenueListener 
interface) via invokeLater.

Please be aware that now running on DEBUG level for the CVS version creates
lots of debug code if you enter the RevenueStep.

I will make the automatic revenue calculation a Game Option tomorrow.

Stefan