rails-devel — List for discussion of Rails development

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

This wasn't so simple as it looked, but I think it now works correctly.

Your saved file had something strange. In previous PR formation rounds, Phil
(correctly) got a turn (to exchange HB) before Chris (to exchange the three
minors). However, in this final case Phil's turn was skipped; it's not clear
to me why. In any case, to make it loadable, I had to truncate the last
action from this saved file. That gave me a nice test case.

To all helpful bug reporters: I'll definitely check out all your reports, as
well as the Sourceforge bugs list, but for various reasons I'm progressing
pretty slowly these days. 

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Friday 11 June 2010 17:31
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] 1835: Later Prussian formation rounds

Okay, putting this one down here since I can't explain this behaviour
either with my understanding of the rules or using the FAQ Erik linked
earlier

End of SR7, the Pr has a 3 and a 4

On everyone passing, one player chooses to merge 3 of his minors,
gifting the Pr a 2+2, 3 and another 3

++++++++++++++++++++++++
Starting Pr formation round
++++++++++++++++++++++++
Chris merges minor M5 into Pr, with 180M cash and 1 train(s)
Chris gets a 5% share of Pr from IPO in exchange for M5
Chris merges minor M1 into Pr, with 155M cash and 1 train(s)
Chris gets a 5% share of Pr from IPO in exchange for M1
Pr exchanges the M1 base token on H2/1
Chris merges minor M4 into Pr, with 70M cash and 1 train(s)
Chris gets a 10% share of Pr from IPO in exchange for M4
Pr exchanges the M4 base token on G5/1
---
Pr discards a 3-train to Pool

Leaving the Pr with 2+2, 3, 3, 4

Firstly, does the president of the Pr not get to choose which trains
are discarded? Secondly, at this stage (4+4 not yet bought) is the
train limit not 3?

Saved file attached immediately after this scenario

Phil

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

It gets a little weirder with the sale of the 4+4, which as I'm aware
shouldn't do anything except cause the 2+2 to rust.  The Pr is forced
to discard one of it's 3s or 4s after it discards it's 2+2 in the
attached save...

Phil

On 13 June 2010 20:10, Phil Davies <de...@gm...> wrote:
>
>
> On 12 Jun 2010, at 20:33, "Erik Vos" <eri...@xs...> wrote:
>
>>
>> [EV] Answers below.
>>
>> Leaving the Pr with 2+2, 3, 3, 4
>>
>> Firstly, does the president of the Pr not get to choose which trains
>> are discarded?
>>
>> [EV] Yes, he does. The PR train discard step at the end of a merge round
>> isn't implemented yet (just forgotten, I'm afraid).
>>
>
> No worries Erik, half the reason I chose to play 1835 this time was to give
> you some playteting feedback :) this is easily an issue we can carry on
> with.
>
>> Secondly, at this stage (4+4 not yet bought) is the
>> train limit not 3?
>>
>> [EV] Yes, but the PR may own one extra train.
>>
>
> Ok, I wasn't sure on this, the 18xx difference list states that the Pr can
> have 3 when everyone else has 2 but it isn't as clear on whether this
> happens in the earlier phases.
>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails 1.3 is now available.

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

Chris Shaffer wrote:
> Actually, for a route terminating in Hamburg, the relevant question
> would be "does the route intersect one of your own tokens elsewhere?" 
> If yes, you can terminate in any Hamburg city circle.  If the only owner
> station token on the route is in Hamburg, then it would matter which
> side of the river it was on and which path was taken to reach it.

Good point.  I'll edit that page on 18xx.net. :)

Re: [Rails-devel] Rails 1.3 is now available.

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

Actually, for a route terminating in Hamburg, the relevant question would be
"does the route intersect one of your own tokens elsewhere?"  If yes, you
can terminate in any Hamburg city circle.  If the only owner station token
on the route is in Hamburg, then it would matter which side of the river it
was on and which path was taken to reach it.

--
Chris

Please consider the environment before printing this e-mail.


On Fri, Jun 11, 2010 at 1:57 AM, Phil Davies <de...@gm...> wrote:

> The tile encyclopaedia does point this out as a source of contention
> amongst players:
>
> http://www.18xx.net/tiles/e221.htm
>
> ' (It is unclear, and a source of argument, whether this reduction
> applies to a run that begins or ends in Hamburg.  If the answer is
> yes, then it makes a difference which side of the river your company's
> station marker is on.  If the answer is no, it does not make any
> difference.)'
>
> I've not played the physical game but the rules reading would imply
> that if for any reason your train cross that central 'ferry' symbol
> representing the river then Hamburg is 10 less.  For a route
> terminating in Hamburg this is irrelevant since you can always
> terminate at another corps station, but for starting out it would be
> important where your token was placed.
>
> On 11 June 2010 05:43, John David Galt <jd...@di...>
> wrote:
> > Stefan Frey (web.de) wrote:
> >> -> Very minor, but a difficult one:
> >> The (chromatic) rule in 1835 for the -10 malus to cross the Elbe in
> Hamburg is
> >> not complete: Currently only the malus is only applied if the train runs
> >> through Hamburg and crosses the Elbe.  There is a second part that is
> not yet
> >> implemented: If a train starts from a base token in Hamburg it is
> important
> >> if that base token lays south (Harburg) or north (City or Altona) the
> river
> >> Elbe.
> >
> > If that is the prevailing view in Germany, then it ought to be brought up
> for
> > discussion on the 18xx list.  Because every group I've played 1835 with
> in the
> > US and Canada plays that it never matters which side of the Elbe your
> token is
> > on: if Hamburg is the beginning or end of your route, you don't suffer
> the
> > penalty.
> >
> >
> ------------------------------------------------------------------------------
> > ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit.  See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

On 12 Jun 2010, at 20:33, "Erik Vos" <eri...@xs...> wrote:

>
> [EV] Answers below.
>
> Leaving the Pr with 2+2, 3, 3, 4
>
> Firstly, does the president of the Pr not get to choose which trains
> are discarded?
>
> [EV] Yes, he does. The PR train discard step at the end of a merge  
> round
> isn't implemented yet (just forgotten, I'm afraid).
>

No worries Erik, half the reason I chose to play 1835 this time was to  
give you some playteting feedback :) this is easily an issue we can  
carry on with.

> Secondly, at this stage (4+4 not yet bought) is the
> train limit not 3?
>
> [EV] Yes, but the PR may own one extra train.
>

Ok, I wasn't sure on this, the 18xx difference list states that the Pr  
can have 3 when everyone else has 2 but it isn't as clear on whether  
this happens in the earlier phases.

>
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 playtest report - Rails 1.3

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

On 13 Jun 2010, at 18:01, John David Galt  
<jd...@di...> wrote:

> I tried a 4 player game last night.
>
> The initial round went as expected, though it was annoying that we  
> were
> compelled to float the By to allow the game to continue (if this  
> were not
> forced, the OB would have been left unpurchased for one round  
> because the
> only one who could afford it was the LD/Sx owner.  This is usual for  
> us).
>
> The map error near Dusseldorf/Essen is fixed now.
>
> The logic to limit which hexes you can lay tiles in seems correct --  
> except
> that (1) it still offers to let the Pfalz owner place Mannheim during
> yellow phase, and (2) it doesn't let you start the game by dropping  
> a token
> in Nurnberg and then build track north from there on turn 1 (which  
> some of
> us believe is legal).
>
> But while that logic "knows" about route connections, the tile  
> rotation
> logic doesn't.  That is, you're still allowed (and sometimes offered  
> as
> first choice) the ability to place a new tile rotated so that it  
> doesn't
> connect to your route.
>
> Also, the controls to place a tile seem annoyingly finicky -- you  
> have to
> click directly on the image of the tile you want to place, even  
> though its
> description takes up a larger space that looks like a button.

> The route calculation logic seems correct when it gives an answer at  
> all.
> But in most turns it did not even guess at a revenue number for By.
>
> I ran into a real show stopper, though, in the stock round when Ba  
> formed.
> I backed up (undid) a couple of turns to test "what ifs".  Then I  
> found out
> the hard way that when you undo the purchase of a Ba share, the  
> share seems
> to get put back on the bottom of the stack!  (That is, after two  
> players
> together bought 60% of Ba, undid two 10% purchases, and redid them,  
> I can't
> buy the seventh share -- it insists the next share I buy be 20%!)
>
This behaviour has already been logged as a bug, the stack order for  
IPO purchases can get strangely broken in certain scenarios.

> At this point I quit.
>
> I also tried out the "Cash Correction" mode just to see if it would  
> help,
> and found that once you select it you can't cancel it without changing
> anything.  Entering zero gets you an error popup.
>
You leave cash correction by selecting 'leave cash correction' under  
the moderator menu. There would never be a reason to enter a 0 cash  
correction.

Phil

> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] 1835 playtest report - Rails 1.3

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

I tried a 4 player game last night.

The initial round went as expected, though it was annoying that we were
compelled to float the By to allow the game to continue (if this were not
forced, the OB would have been left unpurchased for one round because the
only one who could afford it was the LD/Sx owner.  This is usual for us).

The map error near Dusseldorf/Essen is fixed now.

The logic to limit which hexes you can lay tiles in seems correct -- except
that (1) it still offers to let the Pfalz owner place Mannheim during
yellow phase, and (2) it doesn't let you start the game by dropping a token
in Nurnberg and then build track north from there on turn 1 (which some of
us believe is legal).

But while that logic "knows" about route connections, the tile rotation
logic doesn't.  That is, you're still allowed (and sometimes offered as
first choice) the ability to place a new tile rotated so that it doesn't
connect to your route.

Also, the controls to place a tile seem annoyingly finicky -- you have to
click directly on the image of the tile you want to place, even though its
description takes up a larger space that looks like a button.

The route calculation logic seems correct when it gives an answer at all.
But in most turns it did not even guess at a revenue number for By.

I ran into a real show stopper, though, in the stock round when Ba formed.
I backed up (undid) a couple of turns to test "what ifs".  Then I found out
the hard way that when you undo the purchase of a Ba share, the share seems
to get put back on the bottom of the stack!  (That is, after two players
together bought 60% of Ba, undid two 10% purchases, and redid them, I can't
buy the seventh share -- it insists the next share I buy be 20%!)

At this point I quit.

I also tried out the "Cash Correction" mode just to see if it would help,
and found that once you select it you can't cancel it without changing
anything.  Entering zero gets you an error popup.

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

[EV] Answers below.

Leaving the Pr with 2+2, 3, 3, 4

Firstly, does the president of the Pr not get to choose which trains
are discarded? 

[EV] Yes, he does. The PR train discard step at the end of a merge round
isn't implemented yet (just forgotten, I'm afraid). 

Secondly, at this stage (4+4 not yet bought) is the
train limit not 3?

[EV] Yes, but the PR may own one extra train. 

Re: [Rails-devel] 1835: Later Prussian formation rounds

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

On 2010-06-11 07:31, Phil Davies wrote:
> Okay, putting this one down here since I can't explain this behaviour
> either with my understanding of the rules or using the FAQ Erik linked
> earlier
> 
> End of SR7, the Pr has a 3 and a 4
> 
> On everyone passing, one player chooses to merge 3 of his minors,
> gifting the Pr a 2+2, 3 and another 3
> 
> ++++++++++++++++++++++++
> Starting Pr formation round
> ++++++++++++++++++++++++
> Chris merges minor M5 into Pr, with 180M cash and 1 train(s)
> Chris gets a 5% share of Pr from IPO in exchange for M5
> Chris merges minor M1 into Pr, with 155M cash and 1 train(s)
> Chris gets a 5% share of Pr from IPO in exchange for M1
> Pr exchanges the M1 base token on H2/1
> Chris merges minor M4 into Pr, with 70M cash and 1 train(s)
> Chris gets a 10% share of Pr from IPO in exchange for M4
> Pr exchanges the M4 base token on G5/1

It would be nice if the messages listed the trains that each minor has.

> ---
> Pr discards a 3-train to Pool
> 
> Leaving the Pr with 2+2, 3, 3, 4
> 
> Firstly, does the president of the Pr not get to choose which trains
> are discarded? Secondly, at this stage (4+4 not yet bought) is the
> train limit not 3?

He should get to choose.  But the train limit is 4 (Pr is allowed one more
train than other major companies throughout the game).

[Rails-devel] 1835: Later Prussian formation rounds

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

Okay, putting this one down here since I can't explain this behaviour
either with my understanding of the rules or using the FAQ Erik linked
earlier

End of SR7, the Pr has a 3 and a 4

On everyone passing, one player chooses to merge 3 of his minors,
gifting the Pr a 2+2, 3 and another 3

++++++++++++++++++++++++
Starting Pr formation round
++++++++++++++++++++++++
Chris merges minor M5 into Pr, with 180M cash and 1 train(s)
Chris gets a 5% share of Pr from IPO in exchange for M5
Chris merges minor M1 into Pr, with 155M cash and 1 train(s)
Chris gets a 5% share of Pr from IPO in exchange for M1
Pr exchanges the M1 base token on H2/1
Chris merges minor M4 into Pr, with 70M cash and 1 train(s)
Chris gets a 10% share of Pr from IPO in exchange for M4
Pr exchanges the M4 base token on G5/1
---
Pr discards a 3-train to Pool

Leaving the Pr with 2+2, 3, 3, 4

Firstly, does the president of the Pr not get to choose which trains
are discarded? Secondly, at this stage (4+4 not yet bought) is the
train limit not 3?

Saved file attached immediately after this scenario

Phil

Re: [Rails-devel] Rails 1.3 is now available.

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

The tile encyclopaedia does point this out as a source of contention
amongst players:

http://www.18xx.net/tiles/e221.htm

' (It is unclear, and a source of argument, whether this reduction
applies to a run that begins or ends in Hamburg.  If the answer is
yes, then it makes a difference which side of the river your company's
station marker is on.  If the answer is no, it does not make any
difference.)'

I've not played the physical game but the rules reading would imply
that if for any reason your train cross that central 'ferry' symbol
representing the river then Hamburg is 10 less.  For a route
terminating in Hamburg this is irrelevant since you can always
terminate at another corps station, but for starting out it would be
important where your token was placed.

On 11 June 2010 05:43, John David Galt <jd...@di...> wrote:
> Stefan Frey (web.de) wrote:
>> -> Very minor, but a difficult one:
>> The (chromatic) rule in 1835 for the -10 malus to cross the Elbe in Hamburg is
>> not complete: Currently only the malus is only applied if the train runs
>> through Hamburg and crosses the Elbe.  There is a second part that is not yet
>> implemented: If a train starts from a base token in Hamburg it is important
>> if that base token lays south (Harburg) or north (City or Altona) the river
>> Elbe.
>
> If that is the prevailing view in Germany, then it ought to be brought up for
> discussion on the 18xx list.  Because every group I've played 1835 with in the
> US and Canada plays that it never matters which side of the Elbe your token is
> on: if Hamburg is the beginning or end of your route, you don't suffer the
> penalty.
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Fwd: [ rails-Bugs-3013209 ] 1835 stack order from IPO can be messed up

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

On 11 June 2010 05:45, John David Galt <jd...@di...> wrote:
> On 2010-06-08 04:21, Phil Davies wrote:
>> Just raised the following bug on 1835 and thought it worth bringing up
>> for discussion.  I 'think' this is the only other supported game where
>> there are shares of a mixed type available for purchase (1856 has 5%
>> shares but I believe that the CGR is always either a 10% or 5% corp?).
>
> I'm hoping that 1837 will make the list fairly soon; it doesn't have too
> many differences from 1835, and most of those are 1830-like differences.
>
>>  The game status interface doesn't really have the facility for
>> displaying exactly what share is the next available.
>
> When you click on the button to buy from the initial offering, it does ask
> "Buy 2 shares of Wrt for 168?"  While this could be better phrased, it does
> get the job done (and after all, players are expected to own the physical
> game).

This is true, my point was that veteran rails users are used to
mindlessly clicking yes without reading the popup, this is probably a
user failing rather than a product failing :)

> I haven't tried buying such companies from the bank pool, though, and would
> want to have the choice to buy either size of certificate if they are there.
> (This can probably be limited to two sizes in the code -- I don't know of a
> game where any one company, once formed, ever has more than two sizes of
> certificate at one time, unless you count the bank-owned 50% certs in 1862.)

I will find out in the next SR I'm heading into in this 1835 game but
I believe there is a dropdown box that allows you to choose between
which share you would like to purchase, similar to the one that pops
up when you want to sell multiples.  I think it's really only an issue
with the IPO since they are in a predefined 'stack' which you can't
really see.

Phil

Re: [Rails-devel] 1835 Prussian does not pay out (3014303)

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

Huh, okay, that is 'slightly' different to my reading of the rules
itself, which seem to imply that if any prePrussian share has paid
dividends in that OR then the Prussian will not operate in that round
(meaning even if M1 bought the 4, it won't operate because the
privates have paid out).  Fair enough if this is the authors
clarification, that's definitely the way it should be handled.

Erik: apologies, I failed to attach my save file, I was throwing
thoughts at the list whilst trying to resolve the issue myself and
kinda forgot to give you my testcase :)  The save with the issue is
attached to this mail.  I've tried running it against the latest
revision and it does at least progress now, however, it's progressing
incorrectly:

Pr (Simon) operates.
Pr lays tile #3 at hex B14/SW
Pr earns 120M
Pr pays out full dividend of 120M
Phil gets no income for 10% Pr shares as precursors have operated <---
this is wrong
Phil receives 6M for 1 5% shares
Simon receives 18M for 3 5% shares
Pr price goes from 154M(I4) to 172M(J4).

I converted M3 and the BB in the last OR, when the Prussian didn't
run.  I currently hold the HB which is giving me my virtual 10%
'negative share' but this hasn't yet been converted into the Prussian.
 I believe the negative shares are being applied regardless of whether
the attached minor or private has been folded into the Prussian.  They
need to apply only if they have been folded in.

Phil

On 11 June 2010 06:00, John David Galt <jd...@di...> wrote:
> Erik Vos wrote:
>> Thought about this further...I assume this is here for the specific OR
>> for when the 5 gets bought?  In that specific round, it's possible
>> (likely) that the Prussian will run after certs have been forceably
>> merged that have already earned income.  I'm guessing this code is
>> there to prevent a player earning from a cert twice in that specific
>> round, since it's the only round where the Prussian could run and
>> players have already earned from certs.
>>
>> [EV] That's indeed the rule: the PR can run (except when M2 has run), but
>> players who have already earned income from merged preprussians don't get
>> their income. This the official interpretation from the author, see Q5.1 in
>> http://web.archive.org/web/20041024222224/http://www.geocities.com/TimesSqua
>> re/Arena/5276/depot/1835f.htm#5.0
>
> Which means that if M1 buys the first 4 train, or the first 4+4, the PR can
> run that round even though BS, HO, and M1 may have paid dividends and then
> converted to PR shares.  In which case those shares don't pay out.  (It can
> also happen on the first 5 train, as you said, but not *only* then.)
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation details for revenue calculation

[Jonathan F. <jon...@ya...>]

>From what I've seen of AI development, the first step usually is to
>try to implement a "stupid" AI to just prove that the basic
>infrastructure is complete.


For a functional example of this approach, see
http://www.codingthewheel.com/archives/how-i-built-a-working-poker-bot
Building an AI that could just fold every hand was more than half of the work.

-- Jonathan

Re: [Rails-devel] 1835 Prussian does not pay out (3014303)

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

Erik Vos wrote:
> Thought about this further...I assume this is here for the specific OR
> for when the 5 gets bought?  In that specific round, it's possible
> (likely) that the Prussian will run after certs have been forceably
> merged that have already earned income.  I'm guessing this code is
> there to prevent a player earning from a cert twice in that specific
> round, since it's the only round where the Prussian could run and
> players have already earned from certs.
> 
> [EV] That's indeed the rule: the PR can run (except when M2 has run), but
> players who have already earned income from merged preprussians don't get
> their income. This the official interpretation from the author, see Q5.1 in
> http://web.archive.org/web/20041024222224/http://www.geocities.com/TimesSqua
> re/Arena/5276/depot/1835f.htm#5.0

Which means that if M1 buys the first 4 train, or the first 4+4, the PR can
run that round even though BS, HO, and M1 may have paid dividends and then
converted to PR shares.  In which case those shares don't pay out.  (It can
also happen on the first 5 train, as you said, but not *only* then.)

Re: [Rails-devel] Fwd: [ rails-Bugs-3013209 ] 1835 stack order from IPO can be messed up

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

On 2010-06-08 04:21, Phil Davies wrote:
> Just raised the following bug on 1835 and thought it worth bringing up
> for discussion.  I 'think' this is the only other supported game where
> there are shares of a mixed type available for purchase (1856 has 5%
> shares but I believe that the CGR is always either a 10% or 5% corp?).

I'm hoping that 1837 will make the list fairly soon; it doesn't have too
many differences from 1835, and most of those are 1830-like differences.

>  The game status interface doesn't really have the facility for
> displaying exactly what share is the next available.

When you click on the button to buy from the initial offering, it does ask
"Buy 2 shares of Wrt for 168?"  While this could be better phrased, it does
get the job done (and after all, players are expected to own the physical
game).

I haven't tried buying such companies from the bank pool, though, and would
want to have the choice to buy either size of certificate if they are there.
(This can probably be limited to two sizes in the code -- I don't know of a
game where any one company, once formed, ever has more than two sizes of
certificate at one time, unless you count the bank-owned 50% certs in 1862.)

Re: [Rails-devel] Rails 1.3 is now available.

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

Stefan Frey (web.de) wrote:
> -> Very minor, but a difficult one:
> The (chromatic) rule in 1835 for the -10 malus to cross the Elbe in Hamburg is 
> not complete: Currently only the malus is only applied if the train runs 
> through Hamburg and crosses the Elbe.  There is a second part that is not yet 
> implemented: If a train starts from a base token in Hamburg it is important 
> if that base token lays south (Harburg) or north (City or Altona) the river 
> Elbe.

If that is the prevailing view in Germany, then it ought to be brought up for
discussion on the 18xx list.  Because every group I've played 1835 with in the
US and Canada plays that it never matters which side of the Elbe your token is
on: if Hamburg is the beginning or end of your route, you don't suffer the
penalty.

Re: [Rails-devel] 1835 Prussian does not pay out (3014303)

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

See below. 

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Thursday 10 June 2010 13:44
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835 Prussian does not pay out (3014303)

Thought about this further...I assume this is here for the specific OR
for when the 5 gets bought?  In that specific round, it's possible
(likely) that the Prussian will run after certs have been forceably
merged that have already earned income.  I'm guessing this code is
there to prevent a player earning from a cert twice in that specific
round, since it's the only round where the Prussian could run and
players have already earned from certs.

[EV] That's indeed the rule: the PR can run (except when M2 has run), but
players who have already earned income from merged preprussians don't get
their income. This the official interpretation from the author, see Q5.1 in
http://web.archive.org/web/20041024222224/http://www.geocities.com/TimesSqua
re/Arena/5276/depot/1835f.htm#5.0

I can see what's wrong, in our game we have a player who has potential
Prussian certs in the form of minors 1,4 and 5.  But he currently
doesn't have any shares of the Prussian, so at line 128 in
OperatingRound_1835 it is trying to get the shares that this player
has in Pr and throwing a nullpointer exception.

[EV] Ah, that's a bug. Now fixed; but I don't have a good test case, can you
test it?

Erik.

Re: [Rails-devel] Problem buying last new train

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

Hi Chip,
This is a known bug that has been fixed in version 1.3.
Erik.
 


  _____  

From: Chip Welch [mailto:chi...@ho...] 
Sent: Thursday 10 June 2010 01:58
To: rai...@li...
Subject: [Rails-devel] Problem buying last new train


I ran into a problem when buying the last new Diesel train from the bank
IPO. Everything works fine during my turn and I buy the train, click done
and play is supposed to pass to the next player. The Report window shows the
train being bought. But, when I save the game and the next player load the
saved game file, the train is back in the bank and the train does not show
it was purchased. This is happening in a Rails 1.2.2 game and happens every
time. See attached save file prior to buying the last train.

Chip


  _____  

Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
Learn more.
<http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:
WL:en-US:WM_HMP:042010_1>  

Re: [Rails-devel] Problem buying last new train

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

This is a reported bug that is fixed in version 1.3

http://sourceforge.net/tracker/?func=detail&aid=2990413&group_id=132173&atid=723360

--
Chris

Please consider the environment before printing this e-mail.


On Wed, Jun 9, 2010 at 4:57 PM, Chip Welch <chi...@ho...> wrote:

>  I ran into a problem when buying the last new Diesel train from the bank
> IPO. Everything works fine during my turn and I buy the train, click done
> and play is supposed to pass to the next player. The Report window shows the
> train being bought. But, when I save the game and the next player load the
> saved game file, the train is back in the bank and the train does not show
> it was purchased. This is happening in a Rails 1.2.2 game and happens every
> time. See attached save file prior to buying the last train.
>
> Chip
>
> ------------------------------
> Hotmail has tools for the New Busy. Search, chat and e-mail from your
> inbox. Learn more.<http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] 1835 Prussian does not pay out (3014303)

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

Thought about this further...I assume this is here for the specific OR
for when the 5 gets bought?  In that specific round, it's possible
(likely) that the Prussian will run after certs have been forceably
merged that have already earned income.  I'm guessing this code is
there to prevent a player earning from a cert twice in that specific
round, since it's the only round where the Prussian could run and
players have already earned from certs.

I can see what's wrong, in our game we have a player who has potential
Prussian certs in the form of minors 1,4 and 5.  But he currently
doesn't have any shares of the Prussian, so at line 128 in
OperatingRound_1835 it is trying to get the shares that this player
has in Pr and throwing a nullpointer exception.

On 10 June 2010 12:20, Phil Davies <de...@gm...> wrote:
> Just raised the above issue and having a peek to see if I could see
> what was wrong.
>
> It seems that when the Prussian pays out, rails does a check to see if
> any players shouldn't get income from the payout, but I don't
> understand why it is doing that check?  If the Prussian is formed such
> that someone has already earned money from the minor or private that
> is folded into the Prussian, then the Prussian shouldn't run on that
> OR.  If it runs in the next OR...the minors/privates will have been
> folded in at the beginning of that OR when they would not have had a
> chance to earn their owners revenue prior to the Prussian operating.
>
> Am I missing a nuance in the Prussian rules?
>
> Phil
>

[Rails-devel] 1835 Prussian does not pay out (3014303)

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

Just raised the above issue and having a peek to see if I could see
what was wrong.

It seems that when the Prussian pays out, rails does a check to see if
any players shouldn't get income from the payout, but I don't
understand why it is doing that check?  If the Prussian is formed such
that someone has already earned money from the minor or private that
is folded into the Prussian, then the Prussian shouldn't run on that
OR.  If it runs in the next OR...the minors/privates will have been
folded in at the beginning of that OR when they would not have had a
chance to earn their owners revenue prior to the Prussian operating.

Am I missing a nuance in the Prussian rules?

Phil

Re: [Rails-devel] Implementation details for revenue calculation

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

On Wed, Jun 9, 2010 at 8:41 PM, alexti <al...@sh...> wrote:
> Stefan,
>
> I completely agree that AI issue is not an issue of coding at all. From my
> attempts I have feeling that the task if far from trivial. I was trying to
> use naive approach and implement it "as I would play". So basically, in
> the given situation - let's say in the stock round, I would consider what
> tile my company would lay in the following OR and where it would be
> important to place token, so if there's a contention I might be inclined
> to do some buy-selling to readjust operating order. But, of course, that
> have additional implications of affecting who could buy what trains, so
> the advantages of better track lay would have to be weighted against
> (possible) drawbacks of worse train purchase order. And, of course, other
> players could do some stock manipulation to affect the operating order
> too. And then I need to consider if someone might withhold to make a
> critical train purchase, but whether the company would have enough money
> or not would depend on its track lay possibilities of which would be
> affected by the companies operating earlier. And, of course, that order is
> also uncertain.
>

>From what I've seen of AI development, the first step usually is to
try to implement a "stupid" AI to just prove that the basic
infrastructure is complete.

Such an AI might being something like this:

1. In auctions, bid on the first thing that doesn't have a bid. If all
things have bids, then pass. Pass on all contested auctions.
2. In stock rounds, buy the first share that it has enough money to
buy. If it doesn't have enough money to buy, pass. If it's over the
certificate limit, sell the first share it has in its portfolio.
Bankruptcy is treated the same as being over the certificate limit.
3. In operating rounds, lay the first legal tile it can in the default
orientation. Then, if there's sufficient cash in the treasury and has
an available token, play it in the first open, legal placement.
Operate trains based on the best route decided by the routing
algorithm, and always pay out dividends. If there's sufficient cash
and it hasn't maxed out it's train slots, buy the first available
train.

This AI will "play" the game in a very rudimentary way. It's not
flashy, and won't ever win against anyone marginally competent, but it
proves that AI can be created for the game.

Once such an AI has been created, then it's much easier to set about
building a more strategic AI both because we now know that the basic
infrastructure exists and because we now have a blueprint to guide us.

> So the end result is while I can compute individual projections, such as
> number of "what if" scenario, I can't brute-force every viable possibility
> and I am not certain how to filter them out. And that's not even
> considering that I'm overlooking something which I do mentally, but don't
> include into the algorithm (which seemed to happen more often than not).
> Besides all those difficulties, this approach would at best lead to AI
> that plays about at the level of one or more players (such as myself) who
> participated in development. And this doesn't solve the issue of dealing
> with different games.
>
> My current conclusion is that naive approach will not work and the best
> approach is to study AI (which is certainly actively researched area) (or
> to get AI expert as a volunteer on the team :) ). My knowledge of AI
> development is essentially nil. I just thought it is an interesting task
> and start doing it without having any background.
>


It certainly is an interesting field. To be honest, I highly doubt an
AI expert is likely to volunteer for our tiny niche project. So, that
leaves it open to the amateurs and anyone interested enough to learn
how to do it. (Hint. Hint. ;-) )


> In terms of software design, I think the best approach would be to let AI
> use its internal data and query the moderator via some interface. I think
> that AI will have to run in separate thread(s) and it's easier to isolate
> it from the moderator.
>

Sounds like a decent approach to me, and also sounds like a reasonable
starting point. There's a few steps in there that will take some time
before any real AI work can even begin.  To be honest, we don't have
much of a public API to speak of. So, that might be the first place to
start; identifying which methods would be used by external callers,
such as an AI (or a networked client, perhaps). Everything is
single-threaded except for Stefan's route calculation stuff, so there
is likely to be a fair bit of work just creating a separate moderator
(server) from the UI code (client).

> Wrt 2-phased approach. Thanks for the detailed explanation - it confirms
> what I've thought from your previous message. I know why my ordering and
> timing do not fluctuate - for me vertex id is its geographical coordinate,
> so I have determined order everywhere (even though it doesn't make sense).
>
> Alex.
>


Have you checked the code out of CVS?  Maybe that alone is a good
first step. Getting familiar with the code might inspire other ideas
besides AI, if you're not yet keen to take that on. ;-)

---Brett.

> On Wed, 09 Jun 2010 16:19:16 -0600, Stefan Frey (web.de)
> <ste...@we...> wrote:
>
>> Alex,
>> take your time: This is something to have fun.
>>
>> On the issue of implementing AI:
>>
>> I think this is not so much an issue of coding in Java or something
>> else, but
>> having good ideas, sketching out a prototype and/or defining the
>> interfaces
>> to the actual moderator program. A first question would be if the AI
>> should a
>> simplified/abstracted API to query the current state of the game and
>> communicate its actions or should work directly with the Rails
>> objects/actions. But if you choose the first approach you could program
>> against an abstract API and then later an intermediate layer could
>> facilitate
>> the communication between the AI and the rails program.
>>
>> Thus I agree with Brett, that you are invited to add to the project. At
>> least
>> I would already be interested to have a look at your current
>> implemetation
>> and run tests on it. Most likely no one would complain (???), if you
>> commit
>> your code or your designs/ideas to the Rails repo at some separate
>> directory
>> (maybe Brett could suggest a good location).
>>
>> On the issue of the phase two route ordering:
>>
>> Maybe I have not put down things clearly enough.
>>
>> Thus repeating the main finding:
>> For the two phase I first select "cheap" (few overlaps) routes first
>> (regardless of the value of the vertex at the end) and only as a second
>> criteria to use the value of the vertex. This allows to find quickly a
>> good
>> solution, at least for those scenarios we have defined. In consequence
>> this
>> allows to cut the search tree earlier and decreases search time.
>>
>> I suspect that you still assume that I use the route length only as
>> secondary
>> criteria.
>>
>> An example avoids any ambiguity, see below.
>>
>> Stefan
>>
>> Assume you start at vertex A and there are two routes to vertex B (value
>> 40)
>> which have costs (overlaps) of 2 and 4, and two routes to vertex C
>> (value 10)
>> with costs of 0 and 2.
>>
>> Then from A the routes are selected in this sequence:
>> 1) route to C (10) with cost 0
>> 2) route to B (40) with cost 2
>> 3) route to C (10) with cost 2
>> 4) route to B (40) with cost 4
>>
>> Initially I only sorted on value, with undefined ordering of the routes
>> to the
>> same vertex:
>> 1) or 2) route to B (40) with cost 2
>> 1) or 2) route to B (40) with cost 4
>> 3) or 4) route to C (10) with cost 0
>> 3) or 4) route to C (10) with cost 2
>> As I retrieved the edges from a HashSet, the ordering really changed
>> between
>> invocations, even I started the identical scenario, implying the
>> different
>> run times. I assume that in your implementation, you do not explicitly
>> define
>> an ordering, but running the same scenario still had the same ordering
>> implied (if you want to test that, try an explicit randomization).
>>
>> The run times below for the value ordering use the route costs as a
>> second
>> criteria, thus having well defined run times, but worse compared to the
>> sort
>> on the route costs first.
>> Ordering is now:
>> 1) route to B (40) with cost 2
>> 1) route to B (40) with cost 4
>> 3) route to C (10) with cost 0
>> 4) route to C (10) with cost 2
>>
>>
>>
>> On Wednesday 09 June 2010 03:16:53 alexti wrote:
>>> Stefan,
>>>
>>> My comments are inline
>>>
>>> > I have a first phase two prototype working. In fact it was not a too
>>> > difficult
>>> > task, as I only create a multigraph with new edges, that define the
>>> new
>>> > routes.
>>> >
>>> > Then I define "EdgeTravelSets", which define edges that are mutually
>>> > exclusive. This is tracked by the calculator using reference counters,
>>> > as each
>>> > edge might be excluded by several others.
>>>
>>> I'm keeping a vector of exclusions for each edge. I haven't investigated
>>> what approach is more efficient. In the testcases I ran I've never seen
>>> this being a bottleneck, so my guess is that the storage method is
>>> probably unimportant for performance.
>>>
>>> > The first results are promising so far and I believe I found the cause
>>> > for the
>>> > difference in number of evaluations compared to your implementation.
>>> > The main issue is that on a two phase graph the selection of
>>> neighbors is
>>> > different to the original one (by definition).
>>> >
>>> > The effect was that the search for the 4-train set (8, 5+5, 4D, 6E)
>>> took
>>> > between 30 - 140 seconds (compared to 70 seconds without).
>>>
>>> What did the time depend on? I always had very stable times for any
>>> scenario we've tried. For the example above it was ~30 seconds, perhaps
>>> with 1 second spread.
>>>
>>> > At first glance it was amazing that the run time did strongly vary and
>>> > the
>>> > fact that the best  route is found remarkebly late in the process
>>> sheds
>>> > more
>>> > light, why you believe that my revenue predicitor is of the magic
>>> type.
>>> >
>>> > I still sort the neighbors by value, but the ordering of the
>>> (potentially
>>> > multiple) routes to them is random, as they are retrieved from a
>>> HashSet.
>>> > The ordering of routes is important for the revenue predictor to work
>>> > well.
>>> > Finding a good solution quick is important.
>>>
>>> This is a very good point - I choose edge iteration order more or less
>>> randomly - I don't use any criteria to sort them. I kind of thought of
>>> trying to make more intelligent choice, but didn't come up with any good
>>> criterion.
>>>
>>> > Without phase two optimization, the choice to visit the most valuable
>>> > (neighboring) vertex is clearly the optimal approach, as each neigbor
>>> is
>>> > one
>>> > track piece away. Thus the "costs" of each neighbor is identical.
>>> >
>>> > If you have done a phase two optimization, the most valuable vertex
>>> can
>>> > be
>>> > quite far away, thus blocking several track pieces at the same time
>>> and
>>> > ruling out a lot of other connections. Thus for phase two the cost of
>>> > each
>>> > neighboring vertex vary substantially. Accordingly the cost has to be
>>> > considered: The number of edges excluded must be an additional
>>> important
>>> > criteria to select the routes.
>>> >
>>> > Take an example:
>>> > Is it better to run for a nearby 20 vertex (which excludes one other
>>> > route) or
>>> > the far away 50 vertex (which excludes three other routes and
>>> potentially
>>> > bypasses the 10 vertex). There is no clear answer, but our preliminary
>>> > results and my experiences with 18xx routes, implies that it is
>>> usually
>>> > better to go for nearby stations first and save track first.
>>> >
>>> > Thus two approaches are possible:
>>> > * Use Nb of edges excluded as a first criteria, value as a second
>>> only.
>>> > (Thus
>>> > minimize costs first, then maximize revenue).
>>> > In that case you would run to the 20 first.
>>> >
>>> > * Or combine the two and use something like cost-modified value
>>> > approach. For
>>> > example choose the ratio between value and number of routes excluded
>>> > (including the route selected).
>>> > In that case you would run to the 50 first. (20/2 = 10, 50/4 = 12.5)
>>> >
>>> > I have implemented the ordering based on the first idea (cost-based)
>>> and
>>> > the
>>> > time is now stable an 24 seconds run for the 4 train set, thus running
>>> > time
>>> > decreased by factor 3.
>>>
>>> I like your idea, I think it's a good criterion. My intuitive feeling is
>>> that (1) is a better approach. I agree that in normal 18xx games the
>>> routes follow specific pattern - generally people try to connect
>>> valuable
>>> location by the shortest route and the long scenic routes between two
>>> cities/towns is usually a sign of a well blocked map :)
>>>
>>> > Number of evaluations one pass (70 seconds)
>>> > 480961 evaluations, 2935133 predictions and 8828871 edges travelled.
>>> >
>>> > Number of evalutaions two pass with cost ordering (24 seconds)
>>> > 475533 evaluations, 2910152 predictions and 2841394 edges travelled
>>> >
>>> > Number of evaluations two pass with value ordering (81 seconds)
>>> > 1421981 evaluations, 7302480 predictions and 8297888 edges travelled
>>> >
>>> > It seems that edge travelling is the time limiting factor in my
>>> > approach, but
>>> > that is not surprising as evaluation and prediction is pretty cheap
>>> > given the
>>> > continuous update of the run values.
>>>
>>> I want to try to use your approach to the edge ordering, but currently I
>>> took my implementation apart, because I wanted to restore vector
>>> computation functionality (which I broke when I added predictor) and
>>> this
>>> proves to be quite challenging (and, besides, the summer finally came
>>> here
>>>
>>> :) )
>>> :
>>> > To compare the validity of my approach, this are my figures about
>>> > vertices and
>>> > edges:
>>> >
>>> > In scenario A the phase two graph consists of 23 vertices and 57
>>> > edges/routes.
>>> > There are several routes that overlap with 9 other routes (J3.1 ->
>>> J9.1,
>>> > K4.1 -> J3.1,J9.1 -> M2.1,K4.1 -> M2.1).
>>> > In scenario B the numbers are 20 vertices and 151 edges/routes.
>>> > The route that overlaps with most others is E8->D5 (over 19 hexes)
>>> that
>>> > shares
>>> > track with 111 other routes.
>>>
>>> I think I had the same numbers.
>>>
>>> Alex.
>>>
>>> ---------------------------------------------------------------------------
>>> --- ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> 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/
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation details for revenue calculation

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

Stefan,

I completely agree that AI issue is not an issue of coding at all. From my  
attempts I have feeling that the task if far from trivial. I was trying to  
use naive approach and implement it "as I would play". So basically, in  
the given situation - let's say in the stock round, I would consider what  
tile my company would lay in the following OR and where it would be  
important to place token, so if there's a contention I might be inclined  
to do some buy-selling to readjust operating order. But, of course, that  
have additional implications of affecting who could buy what trains, so  
the advantages of better track lay would have to be weighted against  
(possible) drawbacks of worse train purchase order. And, of course, other  
players could do some stock manipulation to affect the operating order  
too. And then I need to consider if someone might withhold to make a  
critical train purchase, but whether the company would have enough money  
or not would depend on its track lay possibilities of which would be  
affected by the companies operating earlier. And, of course, that order is  
also uncertain.

So the end result is while I can compute individual projections, such as  
number of "what if" scenario, I can't brute-force every viable possibility  
and I am not certain how to filter them out. And that's not even  
considering that I'm overlooking something which I do mentally, but don't  
include into the algorithm (which seemed to happen more often than not).  
Besides all those difficulties, this approach would at best lead to AI  
that plays about at the level of one or more players (such as myself) who  
participated in development. And this doesn't solve the issue of dealing  
with different games.

My current conclusion is that naive approach will not work and the best  
approach is to study AI (which is certainly actively researched area) (or  
to get AI expert as a volunteer on the team :) ). My knowledge of AI  
development is essentially nil. I just thought it is an interesting task  
and start doing it without having any background.

In terms of software design, I think the best approach would be to let AI  
use its internal data and query the moderator via some interface. I think  
that AI will have to run in separate thread(s) and it's easier to isolate  
it from the moderator.

Wrt 2-phased approach. Thanks for the detailed explanation - it confirms  
what I've thought from your previous message. I know why my ordering and  
timing do not fluctuate - for me vertex id is its geographical coordinate,  
so I have determined order everywhere (even though it doesn't make sense).

Alex.

On Wed, 09 Jun 2010 16:19:16 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Alex,
> take your time: This is something to have fun.
>
> On the issue of implementing AI:
>
> I think this is not so much an issue of coding in Java or something  
> else, but
> having good ideas, sketching out a prototype and/or defining the  
> interfaces
> to the actual moderator program. A first question would be if the AI  
> should a
> simplified/abstracted API to query the current state of the game and
> communicate its actions or should work directly with the Rails
> objects/actions. But if you choose the first approach you could program
> against an abstract API and then later an intermediate layer could  
> facilitate
> the communication between the AI and the rails program.
>
> Thus I agree with Brett, that you are invited to add to the project. At  
> least
> I would already be interested to have a look at your current  
> implemetation
> and run tests on it. Most likely no one would complain (???), if you  
> commit
> your code or your designs/ideas to the Rails repo at some separate  
> directory
> (maybe Brett could suggest a good location).
>
> On the issue of the phase two route ordering:
>
> Maybe I have not put down things clearly enough.
>
> Thus repeating the main finding:
> For the two phase I first select "cheap" (few overlaps) routes first
> (regardless of the value of the vertex at the end) and only as a second
> criteria to use the value of the vertex. This allows to find quickly a  
> good
> solution, at least for those scenarios we have defined. In consequence  
> this
> allows to cut the search tree earlier and decreases search time.
>
> I suspect that you still assume that I use the route length only as  
> secondary
> criteria.
>
> An example avoids any ambiguity, see below.
>
> Stefan
>
> Assume you start at vertex A and there are two routes to vertex B (value  
> 40)
> which have costs (overlaps) of 2 and 4, and two routes to vertex C  
> (value 10)
> with costs of 0 and 2.
>
> Then from A the routes are selected in this sequence:
> 1) route to C (10) with cost 0
> 2) route to B (40) with cost 2
> 3) route to C (10) with cost 2
> 4) route to B (40) with cost 4
>
> Initially I only sorted on value, with undefined ordering of the routes  
> to the
> same vertex:
> 1) or 2) route to B (40) with cost 2
> 1) or 2) route to B (40) with cost 4
> 3) or 4) route to C (10) with cost 0
> 3) or 4) route to C (10) with cost 2
> As I retrieved the edges from a HashSet, the ordering really changed  
> between
> invocations, even I started the identical scenario, implying the  
> different
> run times. I assume that in your implementation, you do not explicitly  
> define
> an ordering, but running the same scenario still had the same ordering
> implied (if you want to test that, try an explicit randomization).
>
> The run times below for the value ordering use the route costs as a  
> second
> criteria, thus having well defined run times, but worse compared to the  
> sort
> on the route costs first.
> Ordering is now:
> 1) route to B (40) with cost 2
> 1) route to B (40) with cost 4
> 3) route to C (10) with cost 0
> 4) route to C (10) with cost 2
>
>
>
> On Wednesday 09 June 2010 03:16:53 alexti wrote:
>> Stefan,
>>
>> My comments are inline
>>
>> > I have a first phase two prototype working. In fact it was not a too
>> > difficult
>> > task, as I only create a multigraph with new edges, that define the  
>> new
>> > routes.
>> >
>> > Then I define "EdgeTravelSets", which define edges that are mutually
>> > exclusive. This is tracked by the calculator using reference counters,
>> > as each
>> > edge might be excluded by several others.
>>
>> I'm keeping a vector of exclusions for each edge. I haven't investigated
>> what approach is more efficient. In the testcases I ran I've never seen
>> this being a bottleneck, so my guess is that the storage method is
>> probably unimportant for performance.
>>
>> > The first results are promising so far and I believe I found the cause
>> > for the
>> > difference in number of evaluations compared to your implementation.
>> > The main issue is that on a two phase graph the selection of  
>> neighbors is
>> > different to the original one (by definition).
>> >
>> > The effect was that the search for the 4-train set (8, 5+5, 4D, 6E)  
>> took
>> > between 30 - 140 seconds (compared to 70 seconds without).
>>
>> What did the time depend on? I always had very stable times for any
>> scenario we've tried. For the example above it was ~30 seconds, perhaps
>> with 1 second spread.
>>
>> > At first glance it was amazing that the run time did strongly vary and
>> > the
>> > fact that the best  route is found remarkebly late in the process  
>> sheds
>> > more
>> > light, why you believe that my revenue predicitor is of the magic  
>> type.
>> >
>> > I still sort the neighbors by value, but the ordering of the  
>> (potentially
>> > multiple) routes to them is random, as they are retrieved from a  
>> HashSet.
>> > The ordering of routes is important for the revenue predictor to work
>> > well.
>> > Finding a good solution quick is important.
>>
>> This is a very good point - I choose edge iteration order more or less
>> randomly - I don't use any criteria to sort them. I kind of thought of
>> trying to make more intelligent choice, but didn't come up with any good
>> criterion.
>>
>> > Without phase two optimization, the choice to visit the most valuable
>> > (neighboring) vertex is clearly the optimal approach, as each neigbor  
>> is
>> > one
>> > track piece away. Thus the "costs" of each neighbor is identical.
>> >
>> > If you have done a phase two optimization, the most valuable vertex  
>> can
>> > be
>> > quite far away, thus blocking several track pieces at the same time  
>> and
>> > ruling out a lot of other connections. Thus for phase two the cost of
>> > each
>> > neighboring vertex vary substantially. Accordingly the cost has to be
>> > considered: The number of edges excluded must be an additional  
>> important
>> > criteria to select the routes.
>> >
>> > Take an example:
>> > Is it better to run for a nearby 20 vertex (which excludes one other
>> > route) or
>> > the far away 50 vertex (which excludes three other routes and  
>> potentially
>> > bypasses the 10 vertex). There is no clear answer, but our preliminary
>> > results and my experiences with 18xx routes, implies that it is  
>> usually
>> > better to go for nearby stations first and save track first.
>> >
>> > Thus two approaches are possible:
>> > * Use Nb of edges excluded as a first criteria, value as a second  
>> only.
>> > (Thus
>> > minimize costs first, then maximize revenue).
>> > In that case you would run to the 20 first.
>> >
>> > * Or combine the two and use something like cost-modified value
>> > approach. For
>> > example choose the ratio between value and number of routes excluded
>> > (including the route selected).
>> > In that case you would run to the 50 first. (20/2 = 10, 50/4 = 12.5)
>> >
>> > I have implemented the ordering based on the first idea (cost-based)  
>> and
>> > the
>> > time is now stable an 24 seconds run for the 4 train set, thus running
>> > time
>> > decreased by factor 3.
>>
>> I like your idea, I think it's a good criterion. My intuitive feeling is
>> that (1) is a better approach. I agree that in normal 18xx games the
>> routes follow specific pattern - generally people try to connect  
>> valuable
>> location by the shortest route and the long scenic routes between two
>> cities/towns is usually a sign of a well blocked map :)
>>
>> > Number of evaluations one pass (70 seconds)
>> > 480961 evaluations, 2935133 predictions and 8828871 edges travelled.
>> >
>> > Number of evalutaions two pass with cost ordering (24 seconds)
>> > 475533 evaluations, 2910152 predictions and 2841394 edges travelled
>> >
>> > Number of evaluations two pass with value ordering (81 seconds)
>> > 1421981 evaluations, 7302480 predictions and 8297888 edges travelled
>> >
>> > It seems that edge travelling is the time limiting factor in my
>> > approach, but
>> > that is not surprising as evaluation and prediction is pretty cheap
>> > given the
>> > continuous update of the run values.
>>
>> I want to try to use your approach to the edge ordering, but currently I
>> took my implementation apart, because I wanted to restore vector
>> computation functionality (which I broke when I added predictor) and  
>> this
>> proves to be quite challenging (and, besides, the summer finally came  
>> here
>>
>> :) )
>> :
>> > To compare the validity of my approach, this are my figures about
>> > vertices and
>> > edges:
>> >
>> > In scenario A the phase two graph consists of 23 vertices and 57
>> > edges/routes.
>> > There are several routes that overlap with 9 other routes (J3.1 ->  
>> J9.1,
>> > K4.1 -> J3.1,J9.1 -> M2.1,K4.1 -> M2.1).
>> > In scenario B the numbers are 20 vertices and 151 edges/routes.
>> > The route that overlaps with most others is E8->D5 (over 19 hexes)  
>> that
>> > shares
>> > track with 111 other routes.
>>
>> I think I had the same numbers.
>>
>> Alex.
>>
>> ---------------------------------------------------------------------------
>> --- ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> 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] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

Alex,
take your time: This is something to have fun.

On the issue of implementing AI:

I think this is not so much an issue of coding in Java or something else, but 
having good ideas, sketching out a prototype and/or defining the interfaces 
to the actual moderator program. A first question would be if the AI should a 
simplified/abstracted API to query the current state of the game and 
communicate its actions or should work directly with the Rails 
objects/actions. But if you choose the first approach you could program 
against an abstract API and then later an intermediate layer could facilitate 
the communication between the AI and the rails program.

Thus I agree with Brett, that you are invited to add to the project. At least 
I would already be interested to have a look at your current implemetation 
and run tests on it. Most likely no one would complain (???), if you commit 
your code or your designs/ideas to the Rails repo at some separate directory 
(maybe Brett could suggest a good location).

On the issue of the phase two route ordering:

Maybe I have not put down things clearly enough.

Thus repeating the main finding:
For the two phase I first select "cheap" (few overlaps) routes first 
(regardless of the value of the vertex at the end) and only as a second 
criteria to use the value of the vertex. This allows to find quickly a good 
solution, at least for those scenarios we have defined. In consequence this 
allows to cut the search tree earlier and decreases search time.

I suspect that you still assume that I use the route length only as secondary 
criteria.

An example avoids any ambiguity, see below.

Stefan

Assume you start at vertex A and there are two routes to vertex B (value 40) 
which have costs (overlaps) of 2 and 4, and two routes to vertex C (value 10) 
with costs of 0 and 2.

Then from A the routes are selected in this sequence:
1) route to C (10) with cost 0
2) route to B (40) with cost 2
3) route to C (10) with cost 2
4) route to B (40) with cost 4

Initially I only sorted on value, with undefined ordering of the routes to the 
same vertex:
1) or 2) route to B (40) with cost 2
1) or 2) route to B (40) with cost 4
3) or 4) route to C (10) with cost 0
3) or 4) route to C (10) with cost 2
As I retrieved the edges from a HashSet, the ordering really changed between 
invocations, even I started the identical scenario, implying the different 
run times. I assume that in your implementation, you do not explicitly define 
an ordering, but running the same scenario still had the same ordering 
implied (if you want to test that, try an explicit randomization).

The run times below for the value ordering use the route costs as a second 
criteria, thus having well defined run times, but worse compared to the sort 
on the route costs first.
Ordering is now:
1) route to B (40) with cost 2
1) route to B (40) with cost 4
3) route to C (10) with cost 0
4) route to C (10) with cost 2



On Wednesday 09 June 2010 03:16:53 alexti wrote:
> Stefan,
>
> My comments are inline
>
> > I have a first phase two prototype working. In fact it was not a too
> > difficult
> > task, as I only create a multigraph with new edges, that define the new
> > routes.
> >
> > Then I define "EdgeTravelSets", which define edges that are mutually
> > exclusive. This is tracked by the calculator using reference counters,
> > as each
> > edge might be excluded by several others.
>
> I'm keeping a vector of exclusions for each edge. I haven't investigated
> what approach is more efficient. In the testcases I ran I've never seen
> this being a bottleneck, so my guess is that the storage method is
> probably unimportant for performance.
>
> > The first results are promising so far and I believe I found the cause
> > for the
> > difference in number of evaluations compared to your implementation.
> > The main issue is that on a two phase graph the selection of neighbors is
> > different to the original one (by definition).
> >
> > The effect was that the search for the 4-train set (8, 5+5, 4D, 6E) took
> > between 30 - 140 seconds (compared to 70 seconds without).
>
> What did the time depend on? I always had very stable times for any
> scenario we've tried. For the example above it was ~30 seconds, perhaps
> with 1 second spread.
>
> > At first glance it was amazing that the run time did strongly vary and
> > the
> > fact that the best  route is found remarkebly late in the process sheds
> > more
> > light, why you believe that my revenue predicitor is of the magic type.
> >
> > I still sort the neighbors by value, but the ordering of the (potentially
> > multiple) routes to them is random, as they are retrieved from a HashSet.
> > The ordering of routes is important for the revenue predictor to work
> > well.
> > Finding a good solution quick is important.
>
> This is a very good point - I choose edge iteration order more or less
> randomly - I don't use any criteria to sort them. I kind of thought of
> trying to make more intelligent choice, but didn't come up with any good
> criterion.
>
> > Without phase two optimization, the choice to visit the most valuable
> > (neighboring) vertex is clearly the optimal approach, as each neigbor is
> > one
> > track piece away. Thus the "costs" of each neighbor is identical.
> >
> > If you have done a phase two optimization, the most valuable vertex can
> > be
> > quite far away, thus blocking several track pieces at the same time and
> > ruling out a lot of other connections. Thus for phase two the cost of
> > each
> > neighboring vertex vary substantially. Accordingly the cost has to be
> > considered: The number of edges excluded must be an additional important
> > criteria to select the routes.
> >
> > Take an example:
> > Is it better to run for a nearby 20 vertex (which excludes one other
> > route) or
> > the far away 50 vertex (which excludes three other routes and potentially
> > bypasses the 10 vertex). There is no clear answer, but our preliminary
> > results and my experiences with 18xx routes, implies that it is usually
> > better to go for nearby stations first and save track first.
> >
> > Thus two approaches are possible:
> > * Use Nb of edges excluded as a first criteria, value as a second only.
> > (Thus
> > minimize costs first, then maximize revenue).
> > In that case you would run to the 20 first.
> >
> > * Or combine the two and use something like cost-modified value
> > approach. For
> > example choose the ratio between value and number of routes excluded
> > (including the route selected).
> > In that case you would run to the 50 first. (20/2 = 10, 50/4 = 12.5)
> >
> > I have implemented the ordering based on the first idea (cost-based) and
> > the
> > time is now stable an 24 seconds run for the 4 train set, thus running
> > time
> > decreased by factor 3.
>
> I like your idea, I think it's a good criterion. My intuitive feeling is
> that (1) is a better approach. I agree that in normal 18xx games the
> routes follow specific pattern - generally people try to connect valuable
> location by the shortest route and the long scenic routes between two
> cities/towns is usually a sign of a well blocked map :)
>
> > Number of evaluations one pass (70 seconds)
> > 480961 evaluations, 2935133 predictions and 8828871 edges travelled.
> >
> > Number of evalutaions two pass with cost ordering (24 seconds)
> > 475533 evaluations, 2910152 predictions and 2841394 edges travelled
> >
> > Number of evaluations two pass with value ordering (81 seconds)
> > 1421981 evaluations, 7302480 predictions and 8297888 edges travelled
> >
> > It seems that edge travelling is the time limiting factor in my
> > approach, but
> > that is not surprising as evaluation and prediction is pretty cheap
> > given the
> > continuous update of the run values.
>
> I want to try to use your approach to the edge ordering, but currently I
> took my implementation apart, because I wanted to restore vector
> computation functionality (which I broke when I added predictor) and this
> proves to be quite challenging (and, besides, the summer finally came here
>
> :) )
> :
> > To compare the validity of my approach, this are my figures about
> > vertices and
> > edges:
> >
> > In scenario A the phase two graph consists of 23 vertices and 57
> > edges/routes.
> > There are several routes that overlap with 9 other routes (J3.1 -> J9.1,
> > K4.1 -> J3.1,J9.1 -> M2.1,K4.1 -> M2.1).
> > In scenario B the numbers are 20 vertices and 151 edges/routes.
> > The route that overlaps with most others is E8->D5 (over 19 hexes) that
> > shares
> > track with 111 other routes.
>
> I think I had the same numbers.
>
> Alex.
>
> ---------------------------------------------------------------------------
>--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel