rails-devel — List for discussion of Rails development

Re: [Rails-devel] revenue library

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

Erik:
thanks a lot. At least in my case I have to copy the color definitions to my
properties file and uncomment the colors, otherwise I cannot start or load any 
game. Same is true for running from the supplied my.properties without 
uncommenting the error is raised:

Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:169)
	at rails.ui.swing.MapPanel.<init>(MapPanel.java:40)

Stefan
 

On Sunday 16 May 2010 00:46:15 Erik Vos wrote:
> nd another question: Anyone suggest better colors (RGB values) for the
> routing paths. I do not know, if I have time to figure out, how I make
> those
>
> configurable from the properties file.
>
> [EV] I'm willing to look at that.
>
> [EV2] Now done. See the new my.properties file.
>
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] revenue library

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

 
nd another question: Anyone suggest better colors (RGB values) for the 
routing paths. I do not know, if I have time to figure out, how I make those

configurable from the properties file.

[EV] I'm willing to look at that.

[EV2] Now done. See the new my.properties file.

Re: [Rails-devel] revenue library

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

My comments below.
Erik. 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Friday 14 May 2010 17:42
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] revenue library

Some more updates to the revenue calculator:

As a result 1835 is now fully supported.

Open issues:
-> Berlin tile still has to be added to the hand-made tiles (city names to
block double runs to yellow Berlin).

[EV] Does this mean that the one and only function of Station city names in
the Tile definitions is to block multiple runs?
That does not sound very logical to me. Cannot this blocking feature (much)
better be made a (single) MapHex property? Or, if it's colour-dependent, in
TileSet?  Like <NoMultipleAccess/> or such?

-> Hamburg tile has to be layed without rotation, otherwise the Elbe malus
is not applied correctly.

[EV] Now implemented (orientation="0" in TileSet fixes orientation).

-> I assume that Elsac/Lothringen is a single multi-hex off-board area, thus
cannot be included both into a single run (It is not 100% clear from the 
different rules).

[EV] That's what I also would assume.

I do not know, what the general opinion is: I would prefer not too wait too 
long for the next release to get more feedback. Currently we have 1830, 1835

and 1889 with complete support of revenue calculation. All games (except
1851 
with the invisible Birmingham) should have the basic route awareness
working.

[EV] I agree. However, 1856 needs some more retesting (see previous
message).

All others are more complex and require the RevenueModifiers, which I would 
prefer to keep back until the next release. It is possible to add some of
the 
games at minor releases.

My proposal is:
1) Define a gameOption for RevenueCalculation with two settings for now: 
{None, Suggest} for 1830, 1835, 1889
2) Define a gameOption for RouteAwareness with two settings for now:
{None, (Hex)Highlight} for all games, except 1851

An open question is whether the default should be none or one of the active 
ones. If the active selection is chosen, I would suggest, that we add
another 
default for those games saved by previous version ("undefined default") and 
set those to none. Otherwise people might complain that they get a feature, 
that they did not want at the start of their game.

[EV] OK with me. Another idea is to allow defining defaults in
My.properties.

And another question: Anyone suggest better colors (RGB values) for the 
routing paths. I do not know, if I have time to figure out, how I make those

configurable from the properties file.

[EV] I'm willing to look at that.

[Rails-devel] 1835 bug & Hamburg brown tile orientation

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

I have fixed a bug in 1835 at buying the first 5-train: the game would hang
if Prussian formation was already complete at that point.

I have also fixed the brown Hamburg tile orientation, preventing any
rotation, so that Stefan's ferry malus calculation will work as it should.

Erik.

[Rails-devel] Next operating company

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

I have largely rewritten the OR code that assigns the next operating company
after a previous company turn has ended. The old code had the index of the
currently active company as its prime state variable, the new code has the
company itself as such.

The reason for this change is, that once too often I was annoyed by getting
"index out of bounds" errors, in particular with 1835. These problems are
now gone.

However, the catch is that I am not able to fully test 1856 CGR formation
round completion. Past fixes have invalidated almost all my 1856 test cases.
The correct assignment of the next operation company after CGR formation was
one of the bugbears in implementing 1856.

If anyone has saved files of 1856 past the CGR formation (whether it formed
or not), that still worked earlier this week against the current (HEAD)
code, I would be indebted if you could check if these files still load, or
send me such files.

BTW I have also started to implement the 18EU bankruptcy rules (which I had
overlooked before). Currently, the game hangs if a bankruptcy occurs in that
game.

Erik.

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

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

Stefan,

I was just throwing ideas around. My solutions are often influenced by a  
need to run a lot of "what-if" scenarios. So, for example, when I'm  
determining where a company should place a port token, I would run the  
optimal route search using a vector of different bonus definitions  
(corresponding to the placement of port token on different tiles). That  
makes it much more efficient that run separate searches. Those  
considerations wouldn't be applicable to Rails.

Alex.

On Fri, 14 May 2010 10:03:43 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Alex:
> that is one idea, which I use for the simple RevenueBonuses, which lay  
> on a
> Hex or Tile.
>
> For the more complex cases I prefer a "push" approach to a "pull"  
> approach:
> The objects that change reveneues have to register themselves as
> RevenueModifiers. Those are two Interfaces (static and a dynamic version)
> which have to be implemented by the objects that want to modify the  
> revenue
> results.
>
> The major obstacle is my neglectable knowledge about Tokens and  
> BonusTokens in
> Rails. Thus I do not want to change anything there close to the next  
> release.
>
> Stefan
>
>
>>
>> My approach is to include "token" requirements to the bonus definition.
>> For example, for port token in 1856 I have an entry in bonus table (that
>> gives +20 to the city) with 2 requirements: (1) hex must contain port
>> token; (2) company must have port token. Tokens are transferred during  
>> the
>> private company sales and (when applicable) due to direct token sales.
>>
>> Alex.
>>
>> ---------------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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] Improved revenue prediction / different scenario

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

Hi Stefan,

> Memory management should be irrelevant for the Java program, as all  
> variables
> involved are fixed sized arrays, which are defined as final.
I am curious, how do you avoid dynamic memory allocation during the  
iteration through the routes? With the switch to the two-phased approach I  
also couldn't avoid some dynamic sizing in the second phase graph.


>> What exactly 5,651k predictions in your case mean?
>
> Evaluations count the call to the function that sums up the value of all
> trains after all trains are finished.
Can you tell from this number how many times revenue of the route has been  
computed?

> Predictions count the call to the function used after each station visit.
>
> Actually the latest refactoring (I do not evaluate anymore until I reach  
> the
> second station, previously I set that to zero) reduced the number of
> evaluations and predictions:
> The number of evaluations drops to 480k, the number of predictions to
> 2,950k, the number of edges travelled does not change.
> Speed improvement is minor (10-15%).
This sounds like what I was calling revenue of the route computation. Is  
it the place were you total value of cities and apply bonuses?

> I have an outer loop that iterates over the base tokens: After I have
> considered all routes from the first token, I keep that vertex as  
> visited to
> avoid evaluating the identical route again. (All routes with both first  
> and
> another start token are already found from the first route, this will  
> work as
> long as connectivity is symmetric).
Yeah, we have the same approach here (aside of marking vertex vs edge).

Alex.

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

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

Alex:
that is one idea, which I use for the simple RevenueBonuses, which lay on a 
Hex or Tile.

For the more complex cases I prefer a "push" approach to a "pull" approach:
The objects that change reveneues have to register themselves as 
RevenueModifiers. Those are two Interfaces (static and a dynamic version) 
which have to be implemented by the objects that want to modify the revenue 
results. 

The major obstacle is my neglectable knowledge about Tokens and BonusTokens in 
Rails. Thus I do not want to change anything there close to the next release.

Stefan


>
> My approach is to include "token" requirements to the bonus definition.
> For example, for port token in 1856 I have an entry in bonus table (that
> gives +20 to the city) with 2 requirements: (1) hex must contain port
> token; (2) company must have port token. Tokens are transferred during the
> private company sales and (when applicable) due to direct token sales.
>
> Alex.
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Improved revenue prediction / different scenario

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

On 14 May 2010 16:56, Stefan Frey (web.de) <ste...@we...> wrote:
>> I've also realized that on that 4 train case, our algorithms would easily
>> beat human - when I look at the map it's not obvious to me at all what the
>> best run would be :)
>
> I am long lost with founding best routes for those scenarios, but I am not a
> good route finder.
>

On a related note, we just finished playing an 1856 game with revenue
calculation on and we had 5 D runs that were in excess of $1200 by the
end of the game.  No way would I ever have calculated that manually.
I appreciate that D runs are technically probably the easiest for
revenue calc to work out but it saves a massive amount of actual game
time for which I am grateful

Phil

Re: [Rails-devel] Improved revenue prediction / different scenario

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

Hi Alex,
see answers below. 
>
> My speed advantage is likely due to two-phased approach and more efficient
> memory management. I still would like to get more intelligent prediction
> algorithm though :-)

Most likely the difference is from the two-phase approach.
Memory management should be irrelevant for the Java program, as all variables 
involved are fixed sized arrays, which are defined as final.
It will be more the speed of function calls and stack handling.

>
> What exactly 5,651k predictions in your case mean?

Evaluations count the call to the function that sums up the value of all 
trains after all trains are finished.
Predictions count the call to the function used after each station visit.

Actually the latest refactoring (I do not evaluate anymore until I reach the 
second station, previously I set that to zero) reduced the number of 
evaluations and predictions: 
The number of evaluations drops to 480k, the number of predictions to 
2,950k, the number of edges travelled does not change.
Speed improvement is minor (10-15%).

>
> I've actually looked at my approach to the station handling (after
> checking all routes from the first station I simply mark all segments
> connected to this station as "used", so no other route would include this
> station). I can't actually come up with any better method.
>
> When you're saying you "keep start vertices visited", do you mean
> "stations" or you iterate in some other manner (not from the stations)?

That seems identical, except that I do not mark the edges (as they are not 
train specific) as used, I only do that for the vertexes (train-specific). 

I have an outer loop that iterates over the base tokens: After I have 
considered all routes from the first token, I keep that vertex as visited to 
avoid evaluating the identical route again. (All routes with both first and 
another start token are already found from the first route, this will work as 
long as connectivity is symmetric).

>
> I've also realized that on that 4 train case, our algorithms would easily
> beat human - when I look at the map it's not obvious to me at all what the
> best run would be :)

I am long lost with founding best routes for those scenarios, but I am not a 
good route finder.

>
> Alex.
>
>
> On Tue, 11 May 2010 16:12:20 -0600, Stefan Frey (web.de)
>
> <ste...@we...> wrote:
> > Hi Alex,
> > but you are still faster and get more scenic routes, thus you should not
> > be
> > too concerned :-)
> >
> > And I did 565k evaluations plus 5,651k predictions, compared to this
> > number it
> > is only 10 times less. The only optimization (or better avoidance of
> > unnecessary duplication) I have not talked about is that I keep the start
> > vertices visited, when I move to the next start vertex. All possible
> > routes
> > which include the previous start vertex are already run from that vertex.
> >
> > Otherwise we should go back to much simpler examples to compare, but I
> > do not
> > have much hope to get similar numbers as long as I do not have
> > implemented
> > the two-phase approach.
> >
> > Stefan
> >
> > On Tuesday 04 May 2010 07:37:39 alexti wrote:
> >> Hi Stefan,
> >>
> >> Thanks for the explanation. I think I understand what you're doing; I
> >> wasn't doing exactly the same and changing my algorithm brought some
> >> improvement, but as usual it was not that big - I'm starting to feel you
> >> have some kind of magic predictor ;-)
> >>
> >> I've run your scenario and my algorithm found the same set of routes,
> >> however it was able to find more scenic route between M6 and L11 for 5+5
> >> train :) It took 46s. Here are my stats.
> >>
> >> Routes found in 45.9643s
> >> [4:340] {E12,C10.SE,C10.NW,B9,B11,A10.N,A8.S,A8.N,A4.S,A4.N,A2.S}
> >> [8:290]
> >> {N1.SW,M2,L3.NE,L3.SW,K4,J3,J5,G6.NE,G6.NW,F5,E6.NE,E6.NW,D5,B3.SE,B3.NW
> >>,A2 .SE} [10:230]
> >> {E12,H13,I14.NE,J13.SW,J13.NE,L11,M8,M10,M6,L5.SE,L5.NW,K4,J5,H3}
> >> [6:240]
> >> {N1.S,N3.N,N3.SW,M4.NE,M4.NW,L3.SE,L3.NW,J3,H3,F5,D5,D7.N,D7.NW,C6.SE,C6
> >>.SW ,B7,B9,C8.SW,C8.S,C10.N,C10.SW,B11} 50,125,612 routes tried
> >>
> >> The frustrating (to me) part is that you've done only 564,805 while I
> >> did
> >> over 50 millions (almost 100 times more). I am not sure how you manage
> >> to
> >> eliminate so many possibilities. I know that my algorithm doesn't handle
> >> multiple stations efficiently - essentially it scales linearly with
> >> number
> >> of stations. I have not thought about it yet, but it still wouldn't
> >> explain the difference.
> >>
> >> Maybe I'm overlooking something. Or maybe I have some bug in the
> >> implementation that doesn't eliminate something I think it does :)
> >>
> >> Thanks,
> >> Alex.
> >>
> >> On Sun, 02 May 2010 13:20:14 -0600, Stefan Frey <ste...@we...>
> >>
> >> wrote:
> >> > Alex,
> >> > sorry for not answering earlier to the question about the improved
> >> > revenue
> >> > prediction.
> >> >
> >> > The scheme is simple.  Assume that N is the number of trains in the
> >> > trainset.
> >> > First I replace the maximum revenue potential of each single train by
> >>
> >> the
> >>
> >> > maximum results of running each train alone.
> >> >
> >> > If there are more than two trains to run:
> >> > Start with J=N-1 and decrease J with each step until J=1.
> >> > - Run the combined set of trains [J, ... N] and use the optimal
> >>
> >> result to
> >>
> >> > predict the maximum future revenue potential of that train set.
> >> >
> >> > Then run the combined optimization of all trains, given the maximum
> >> > revenue
> >> > potential for each set [J, N], with J > 1.
> >> >
> >> > I would like to compare another scenario based on the track network A
> >>
> >> to
> >>
> >> > check
> >> > if we get the same results.
> >> > The changes are:
> >> > - SLSF has 4 tokens now (D5, J3, L11, E12)
> >> > - Trains running are 6E, 8, 5+5, 4D
> >> > (E: ignores towns, D: ignores towns and double city and offboard
> >>
> >> values)
> >>
> >> > The best run I find is 1100. Total running time 78 sec.
> >> > Network runs (6E cyan, 8 pink, 5+5 orange, 4D gray)  and log is
> >>
> >> attached.
> >>
> >> > Stefan
> >
> > -------------------------------------------------------------------------
> >-----
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] revenue library

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

Some more updates to the revenue calculator:

As a result 1835 is now fully supported.

Open issues:
-> Berlin tile still has to be added to the hand-made tiles (city names to
block double runs to yellow Berlin).

-> Hamburg tile has to be layed without rotation, otherwise the Elbe malus
is not applied correctly.

-> I assume that Elsac/Lothringen is a single multi-hex off-board area, thus
cannot be included both into a single run (It is not 100% clear from the 
different rules).

General Changes are:
-> Complex bonuses (multi-vertex) are possible (as in HH).
-> All vertices with special conditions are protected throughout the graph
optimization.
-> The message box shows now the individual value of each train and adds
line breaks for long runs. Complex Bonuses are shown at the end of the run, 
simple bonuses as a "+ xx" value  for the vertex.

I do not know, what the general opinion is: I would prefer not too wait too 
long for the next release to get more feedback. Currently we have 1830, 1835 
and 1889 with complete support of revenue calculation. All games (except 1851 
with the invisible Birmingham) should have the basic route awareness working.

All others are more complex and require the RevenueModifiers, which I would 
prefer to keep back until the next release. It is possible to add some of the 
games at minor releases.

My proposal is:
1) Define a gameOption for RevenueCalculation with two settings for now: 
{None, Suggest} for 1830, 1835, 1889
2) Define a gameOption for RouteAwareness with two settings for now:
{None, (Hex)Highlight} for all games, except 1851

An open question is whether the default should be none or one of the active 
ones. If the active selection is chosen, I would suggest, that we add another 
default for those games saved by previous version ("undefined default") and 
set those to none. Otherwise people might complain that they get a feature, 
that they did not want at the start of their game.

And another question: Anyone suggest better colors (RGB values) for the 
routing paths. I do not know, if I have time to figure out, how I make those 
configurable from the properties file.

Stefan

Re: [Rails-devel] Closing companies

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

It's possible either cancel got pushed or I used undo to go back and
do it again, we seem to frequently go back and forth on our games :p

Cool, thanks for letting me know, I won't update my code till this
game is over but then I'll try running through the game steps manually
again to check it works with '56

Phil

On 13 May 2010 10:49, Erik Vos <eri...@xs...> wrote:
> It turns out, that the saved BuyTrain action did not specify the exchanged
> train name. The only possible cause I could find is that the Cancel button
> had been pressed on the question which train should be exchanged (in this
> case: the 4 or the 5-train). Hitting Cancel was not adequately catched in
> the UI code, and the missing exchanged train was not catched in the server
> validation code either.
>
> I have tightened both pieces of code (testing with an 1830 saved file) and
> it now seems to work OK. The sad result is, that your saved file is now
> invalid and will no longer load...
>
> Erik.
>
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Wednesday 12 May 2010 11:06
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Closing companies
>
> Excellent, confirmed as working, although, I notice on loading up this
> same save file that GW has 5 5 D in trains...that's not right, it
> should have 5D with a 5 in the pool, so it looks like the issue of
> exchanges for D's not working correctly from saved files is back
> again.  Interestingly trying to load this save file in the list and
> fix save files utility, you get a nullpointer exception when it tries
> to load action 547 (which I believe is the action to exchange the 5
> for the D)
>
> Phil
>
> On 11 May 2010 20:50, Erik Vos <eri...@xs...> wrote:
>> It was a typo (first character not uppercased) in StockMarket.xml. Duh.
>> Fixed now.
>>
>> Erik.
>>
>> -----Original Message-----
>> From: Phil Davies [mailto:de...@gm...]
>> Sent: Tuesday 11 May 2010 17:23
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Closing companies
>>
>> ...and after actually reading the bug tracker instead of firing off
>> random emails, I see it is logged.  Attached is a save file, just sell
>> one share of BBG and you are there.
>>
>> Phil
>>
>> On 11 May 2010 16:11, Phil Davies <de...@gm...> wrote:
>>> Has anyone implemented closing companies yet?  I've on the receiving
>>> end of a rather brutal few turns play in 1856 and we just pushed a
>>> company into the closed area of the board, yet nothing has happened.
>>> I can see a <ClosesCompany/> tag on the StockMarket but is this
>>> checked and acted on or is this still pending?
>>>
>>> Phil
>>>
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>>
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
> ----------------------------------------------------------------------------
> --
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Closing companies

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

It turns out, that the saved BuyTrain action did not specify the exchanged
train name. The only possible cause I could find is that the Cancel button
had been pressed on the question which train should be exchanged (in this
case: the 4 or the 5-train). Hitting Cancel was not adequately catched in
the UI code, and the missing exchanged train was not catched in the server
validation code either.

I have tightened both pieces of code (testing with an 1830 saved file) and
it now seems to work OK. The sad result is, that your saved file is now
invalid and will no longer load...

Erik.


-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Wednesday 12 May 2010 11:06
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Closing companies

Excellent, confirmed as working, although, I notice on loading up this
same save file that GW has 5 5 D in trains...that's not right, it
should have 5D with a 5 in the pool, so it looks like the issue of
exchanges for D's not working correctly from saved files is back
again.  Interestingly trying to load this save file in the list and
fix save files utility, you get a nullpointer exception when it tries
to load action 547 (which I believe is the action to exchange the 5
for the D)

Phil

On 11 May 2010 20:50, Erik Vos <eri...@xs...> wrote:
> It was a typo (first character not uppercased) in StockMarket.xml. Duh.
> Fixed now.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Tuesday 11 May 2010 17:23
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Closing companies
>
> ...and after actually reading the bug tracker instead of firing off
> random emails, I see it is logged.  Attached is a save file, just sell
> one share of BBG and you are there.
>
> Phil
>
> On 11 May 2010 16:11, Phil Davies <de...@gm...> wrote:
>> Has anyone implemented closing companies yet?  I've on the receiving
>> end of a rather brutal few turns play in 1856 and we just pushed a
>> company into the closed area of the board, yet nothing has happened.
>> I can see a <ClosesCompany/> tag on the StockMarket but is this
>> checked and acted on or is this still pending?
>>
>> Phil
>>
>
>
>
----------------------------------------------------------------------------
--
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

----------------------------------------------------------------------------
--

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Closing companies

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

Excellent, confirmed as working, although, I notice on loading up this
same save file that GW has 5 5 D in trains...that's not right, it
should have 5D with a 5 in the pool, so it looks like the issue of
exchanges for D's not working correctly from saved files is back
again.  Interestingly trying to load this save file in the list and
fix save files utility, you get a nullpointer exception when it tries
to load action 547 (which I believe is the action to exchange the 5
for the D)

Phil

On 11 May 2010 20:50, Erik Vos <eri...@xs...> wrote:
> It was a typo (first character not uppercased) in StockMarket.xml. Duh.
> Fixed now.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Tuesday 11 May 2010 17:23
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Closing companies
>
> ...and after actually reading the bug tracker instead of firing off
> random emails, I see it is logged.  Attached is a save file, just sell
> one share of BBG and you are there.
>
> Phil
>
> On 11 May 2010 16:11, Phil Davies <de...@gm...> wrote:
>> Has anyone implemented closing companies yet?  I've on the receiving
>> end of a rather brutal few turns play in 1856 and we just pushed a
>> company into the closed area of the board, yet nothing has happened.
>> I can see a <ClosesCompany/> tag on the StockMarket but is this
>> checked and acted on or is this still pending?
>>
>> Phil
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Improved revenue prediction / different scenario

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

Hi Stefan,

My speed advantage is likely due to two-phased approach and more efficient  
memory management. I still would like to get more intelligent prediction  
algorithm though :-)

What exactly 5,651k predictions in your case mean?

I've actually looked at my approach to the station handling (after  
checking all routes from the first station I simply mark all segments  
connected to this station as "used", so no other route would include this  
station). I can't actually come up with any better method.

When you're saying you "keep start vertices visited", do you mean  
"stations" or you iterate in some other manner (not from the stations)?

Meanwhile, I've spotted some epic stupidity in my code and after removing  
it my time on that example went down to 30s.

I've started to work on more sophisticated predictor; but now I don't  
exactly understand what it is doing and it doesn't always work correctly.  
Even when I get it right, I am not sure if it will be any better :(

I've also realized that on that 4 train case, our algorithms would easily  
beat human - when I look at the map it's not obvious to me at all what the  
best run would be :)

Alex.


On Tue, 11 May 2010 16:12:20 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Hi Alex,
> but you are still faster and get more scenic routes, thus you should not  
> be
> too concerned :-)
>
> And I did 565k evaluations plus 5,651k predictions, compared to this  
> number it
> is only 10 times less. The only optimization (or better avoidance of
> unnecessary duplication) I have not talked about is that I keep the start
> vertices visited, when I move to the next start vertex. All possible  
> routes
> which include the previous start vertex are already run from that vertex.
>
> Otherwise we should go back to much simpler examples to compare, but I  
> do not
> have much hope to get similar numbers as long as I do not have  
> implemented
> the two-phase approach.
>
> Stefan
>
>
> On Tuesday 04 May 2010 07:37:39 alexti wrote:
>> Hi Stefan,
>>
>> Thanks for the explanation. I think I understand what you're doing; I
>> wasn't doing exactly the same and changing my algorithm brought some
>> improvement, but as usual it was not that big - I'm starting to feel you
>> have some kind of magic predictor ;-)
>>
>> I've run your scenario and my algorithm found the same set of routes,
>> however it was able to find more scenic route between M6 and L11 for 5+5
>> train :) It took 46s. Here are my stats.
>>
>> Routes found in 45.9643s
>> [4:340] {E12,C10.SE,C10.NW,B9,B11,A10.N,A8.S,A8.N,A4.S,A4.N,A2.S}
>> [8:290]
>> {N1.SW,M2,L3.NE,L3.SW,K4,J3,J5,G6.NE,G6.NW,F5,E6.NE,E6.NW,D5,B3.SE,B3.NW,A2
>> .SE} [10:230]
>> {E12,H13,I14.NE,J13.SW,J13.NE,L11,M8,M10,M6,L5.SE,L5.NW,K4,J5,H3}  
>> [6:240]
>> {N1.S,N3.N,N3.SW,M4.NE,M4.NW,L3.SE,L3.NW,J3,H3,F5,D5,D7.N,D7.NW,C6.SE,C6.SW
>> ,B7,B9,C8.SW,C8.S,C10.N,C10.SW,B11} 50,125,612 routes tried
>>
>> The frustrating (to me) part is that you've done only 564,805 while I  
>> did
>> over 50 millions (almost 100 times more). I am not sure how you manage  
>> to
>> eliminate so many possibilities. I know that my algorithm doesn't handle
>> multiple stations efficiently - essentially it scales linearly with  
>> number
>> of stations. I have not thought about it yet, but it still wouldn't
>> explain the difference.
>>
>> Maybe I'm overlooking something. Or maybe I have some bug in the
>> implementation that doesn't eliminate something I think it does :)
>>
>> Thanks,
>> Alex.
>>
>> On Sun, 02 May 2010 13:20:14 -0600, Stefan Frey <ste...@we...>  
>> wrote:
>> > Alex,
>> > sorry for not answering earlier to the question about the improved
>> > revenue
>> > prediction.
>> >
>> > The scheme is simple.  Assume that N is the number of trains in the
>> > trainset.
>> > First I replace the maximum revenue potential of each single train by  
>> the
>> > maximum results of running each train alone.
>> >
>> > If there are more than two trains to run:
>> > Start with J=N-1 and decrease J with each step until J=1.
>> > - Run the combined set of trains [J, ... N] and use the optimal  
>> result to
>> > predict the maximum future revenue potential of that train set.
>> >
>> > Then run the combined optimization of all trains, given the maximum
>> > revenue
>> > potential for each set [J, N], with J > 1.
>> >
>> > I would like to compare another scenario based on the track network A  
>> to
>> > check
>> > if we get the same results.
>> > The changes are:
>> > - SLSF has 4 tokens now (D5, J3, L11, E12)
>> > - Trains running are 6E, 8, 5+5, 4D
>> > (E: ignores towns, D: ignores towns and double city and offboard  
>> values)
>> > The best run I find is 1100. Total running time 78 sec.
>> > Network runs (6E cyan, 8 pink, 5+5 orange, 4D gray)  and log is  
>> attached.
>> >
>> > Stefan
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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

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

Hi Stefan,

On Tue, 11 May 2010 16:37:18 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> 1856
> Bonus tokens: When and how to create the RevenueBonus?
> (=> StaticRevenueModifier)
>
> 18AL
> Bonus tokens and Named trains: When and how to create the RevenueBonus?
> (=> StaticRevenueModifier)

My approach is to include "token" requirements to the bonus definition.  
For example, for port token in 1856 I have an entry in bonus table (that  
gives +20 to the city) with 2 requirements: (1) hex must contain port  
token; (2) company must have port token. Tokens are transferred during the  
private company sales and (when applicable) due to direct token sales.

Alex.

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

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

 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Wednesday 12 May 2010 00:37
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

1835:
Hamburg: (Multiple) RevenueBonus(es)
Open Question here if and how an invalid orientation of the brown Hamburg
tile 
can be prevented.

[EV] I will look at that. Guess the orientation can be fixed in TileSet.xml.

1851
Birmingham: does not exist until Phase 4
Most likely this should be implemented outside of the revenue part. I would 
prefer that the hex is empty until phase 4 and that the phase change
triggers 
the lay of that tile.

[EV] I'll think about it. 

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

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

Another overview of the implementation details:

The implementation plan has changed:
1. 1830, 1889: done
2. 1835: very close
3. 18Kaas, 18EU: close
4. 1851, 1856, 18AL: not in the upcoming release

I expect with that after this weekend all games up to 
the third group will be supported.

Stefan

Specific implementations:

1830: VertexVisitSets (see previous mail)
1889: RevenueBonus (see previous mail)

1835:
Berlin: VertexVisitSets
Hamburg: (Multiple) RevenueBonus(es)
Open Question here if and how an invalid orientation of the brown Hamburg tile 
can be prevented.

18EU:
Offboard-2-Offboard: StaticRevenueModifier that creates RevenueBonus(es)
Hamburg: Definition of an additional sink vertex 
Paris, Berlin, Vienna: VertexVisitSets
Pullman: DynamicRevenueModifier

18Kaas:
Ruhr: StaticRevenueModifier that creates RevenueBonus(es)

Not yet decided:
The main issue for those games is that I have no own experience playing those, 
thus I have to test them more carefully first.

1851
Offboard-2-Offboard: see 18EU
Birmingham/Johnson City: RevenueBonus (phase dependent)
Birmingham: does not exist until Phase 4
Most likely this should be implemented outside of the revenue part. I would 
prefer that the hex is empty until phase 4 and that the phase change triggers 
the lay of that tile.

1856
Bonus tokens: When and how to create the RevenueBonus? 
(=> StaticRevenueModifier)

18AL
Bonus tokens and Named trains: When and how to create the RevenueBonus?
(=> StaticRevenueModifier)

------------------------------------------------------------------------------
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Improved revenue prediction / different scenario

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

Hi Alex,
but you are still faster and get more scenic routes, thus you should not be 
too concerned :-)

And I did 565k evaluations plus 5,651k predictions, compared to this number it 
is only 10 times less. The only optimization (or better avoidance of 
unnecessary duplication) I have not talked about is that I keep the start 
vertices visited, when I move to the next start vertex. All possible routes 
which include the previous start vertex are already run from that vertex.

Otherwise we should go back to much simpler examples to compare, but I do not 
have much hope to get similar numbers as long as I do not have implemented 
the two-phase approach.

Stefan


On Tuesday 04 May 2010 07:37:39 alexti wrote:
> Hi Stefan,
>
> Thanks for the explanation. I think I understand what you're doing; I
> wasn't doing exactly the same and changing my algorithm brought some
> improvement, but as usual it was not that big - I'm starting to feel you
> have some kind of magic predictor ;-)
>
> I've run your scenario and my algorithm found the same set of routes,
> however it was able to find more scenic route between M6 and L11 for 5+5
> train :) It took 46s. Here are my stats.
>
> Routes found in 45.9643s
> [4:340] {E12,C10.SE,C10.NW,B9,B11,A10.N,A8.S,A8.N,A4.S,A4.N,A2.S}
> [8:290]
> {N1.SW,M2,L3.NE,L3.SW,K4,J3,J5,G6.NE,G6.NW,F5,E6.NE,E6.NW,D5,B3.SE,B3.NW,A2
>.SE} [10:230]
> {E12,H13,I14.NE,J13.SW,J13.NE,L11,M8,M10,M6,L5.SE,L5.NW,K4,J5,H3} [6:240]
> {N1.S,N3.N,N3.SW,M4.NE,M4.NW,L3.SE,L3.NW,J3,H3,F5,D5,D7.N,D7.NW,C6.SE,C6.SW
>,B7,B9,C8.SW,C8.S,C10.N,C10.SW,B11} 50,125,612 routes tried
>
> The frustrating (to me) part is that you've done only 564,805 while I did
> over 50 millions (almost 100 times more). I am not sure how you manage to
> eliminate so many possibilities. I know that my algorithm doesn't handle
> multiple stations efficiently - essentially it scales linearly with number
> of stations. I have not thought about it yet, but it still wouldn't
> explain the difference.
>
> Maybe I'm overlooking something. Or maybe I have some bug in the
> implementation that doesn't eliminate something I think it does :)
>
> Thanks,
> Alex.
>
> On Sun, 02 May 2010 13:20:14 -0600, Stefan Frey <ste...@we...> wrote:
> > Alex,
> > sorry for not answering earlier to the question about the improved
> > revenue
> > prediction.
> >
> > The scheme is simple.  Assume that N is the number of trains in the
> > trainset.
> > First I replace the maximum revenue potential of each single train by the
> > maximum results of running each train alone.
> >
> > If there are more than two trains to run:
> > Start with J=N-1 and decrease J with each step until J=1.
> > - Run the combined set of trains [J, ... N] and use the optimal result to
> > predict the maximum future revenue potential of that train set.
> >
> > Then run the combined optimization of all trains, given the maximum
> > revenue
> > potential for each set [J, N], with J > 1.
> >
> > I would like to compare another scenario based on the track network A to
> > check
> > if we get the same results.
> > The changes are:
> > - SLSF has 4 tokens now (D5, J3, L11, E12)
> > - Trains running are 6E, 8, 5+5, 4D
> > (E: ignores towns, D: ignores towns and double city and offboard values)
> > The best run I find is 1100. Total running time 78 sec.
> > Network runs (6E cyan, 8 pink, 5+5 orange, 4D gray)  and log is attached.
> >
> > Stefan

Re: [Rails-devel] revenue library

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

Freek,
thanks for the compliments and the fix to the built script.
Stefan

Some more updates to changes to the revenue calculator:
The result is that 1830 and 1889 are now the first games, which are fully 
supported.

The changes are:
-> Stations with identical city attributes are automatically defined 
as "vertexVisitSets" for the revenue calculator. Thus each station sets all 
other stations to be already visited. For offboard stations the attribute 
defined for the hex is used, for all other stations the tile definition is 
the relevant one.

This prevents a train to run twice into multiple-hex off-board locations. For 
tiles with multiple stations (e.g. Berlin in 1835), where only one can 
visited per run, the city tag has to be defined accordingly.

-> For hexes and tiles RevenueBonuses can be defined.

An example for the syntax is:
<RevenueBonus value="40"> <Vertex id="-1"/> <Train type="D"/> </RevenueBonus>
(That is the one used for 1889 off-board locations).
An additional tag <Phase name=""/> is available.

All tags can be used more than once per each RevenueBonus, trains and phases 
are "OR" connected, vertices "AND".
 
This allows the already mentioned 1889 diesel bonuses and the HH Elbe crossing 
malus in 1835. In addition those are basic elements for RevenueModifiers, 
which will allow to implement more complicated bonuses.


On Sunday 09 May 2010 00:10:07 Freek Dijkstra wrote:
> Stefan, and all others who helped,
>
> My compliments for the revenue calculator. It looks awesome already!
>
> I just did a minor commit adding the graph libraries to the classpath in
> build.xml; without it, it did not run. (This is only relevant for those
> who use ant to build the app).
>
> Regards,
> Freek
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 updates

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

Is it in fact worth maybe adding a switch to the games.xml or
something that might prevent the games showing up in the selection
list?  It does seem messy that have we what is clearly in development
games showing up with the released versions, although if they are
sorted to the bottom, I would hope people don't have a big problem
with this, more often than not for a real game you are using the load
button anyway!


[EV] That could be done by removing these games from Games.xml. Developers
and testers could then use their own version of that file. Mine is aptly
named MyGames.xml. There is a command-line switch for that purpose:
-Dgamesxmlfile=MyGames.xml

Re: [Rails-devel] Closing companies

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

It was a typo (first character not uppercased) in StockMarket.xml. Duh.
Fixed now.

Erik. 

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Tuesday 11 May 2010 17:23
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Closing companies

...and after actually reading the bug tracker instead of firing off
random emails, I see it is logged.  Attached is a save file, just sell
one share of BBG and you are there.

Phil

On 11 May 2010 16:11, Phil Davies <de...@gm...> wrote:
> Has anyone implemented closing companies yet?  I've on the receiving
> end of a rather brutal few turns play in 1856 and we just pushed a
> company into the closed area of the board, yet nothing has happened.
> I can see a <ClosesCompany/> tag on the StockMarket but is this
> checked and acted on or is this still pending?
>
> Phil
>

Re: [Rails-devel] Closing companies

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

...and after actually reading the bug tracker instead of firing off
random emails, I see it is logged.  Attached is a save file, just sell
one share of BBG and you are there.

Phil

On 11 May 2010 16:11, Phil Davies <de...@gm...> wrote:
> Has anyone implemented closing companies yet?  I've on the receiving
> end of a rather brutal few turns play in 1856 and we just pushed a
> company into the closed area of the board, yet nothing has happened.
> I can see a <ClosesCompany/> tag on the StockMarket but is this
> checked and acted on or is this still pending?
>
> Phil
>

[Rails-devel] Closing companies

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

Has anyone implemented closing companies yet?  I've on the receiving
end of a rather brutal few turns play in 1856 and we just pushed a
company into the closed area of the board, yet nothing has happened.
I can see a <ClosesCompany/> tag on the StockMarket but is this
checked and acted on or is this still pending?

Phil

Re: [Rails-devel] 1835 updates

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

>
> The Games List has been reorganized to put the games in playability order.
> You'll no longer be annoyed (as I was) by finding the yet experimental 1825
> at the top.

That makes a lot more sense (and increases my guilt at having very
little done on this recently!)

Is it in fact worth maybe adding a switch to the games.xml or
something that might prevent the games showing up in the selection
list?  It does seem messy that have we what is clearly in development
games showing up with the released versions, although if they are
sorted to the bottom, I would hope people don't have a big problem
with this, more often than not for a real game you are using the load
button anyway!

Phil