rails-devel — List for discussion of Rails development

[Rails-devel] Usability options for route awareness and revenue calculation

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

Hi,
I would like to focus the discussion on the question in which ways
the revenue calculation and route awareness should be available to the 
players.

I first start with comments on two recent e-mails on that topic.

I am myself not sure for now, if I will like playing with automatic revenue 
calculation. For sure in the last ORs, but in the beginning of the game?
And I still like a real map, please someone come up with an implementation for
an observing camera, which generates the according tile lays for Rails ;-)

Jim Black wrote 2010-04-06:
> I hope that- perhaps, as a preliminary feature to Rails-calculated routes-
> users will simply be able to outline their routes directly in Rails (by
> selecting the track, along the way)- 'route specification', if you will.
>
> I know automatic calculation is a very popular, heavily requested feature.
>
> Still, to me- 'route specification' is probably more important/fundamental
> than 'automatic route calculation'.

Current status:
For now the route awareness is only used to highlight potential locations
for extensions of the routes. It does not enforce anything more than Rails 
already does.

My suggestion is to add a menu-item in the GUI that turns that on/off. See an 
different approach at the end of the mail.

Future solution:
Have a game option for each game that allows to set the route enforcing to
-> none
-> permissive
-> restrictive
-> semi-restrictive
with the default option set to the official rule for that game.
Compare:
http://www.fwtwr.com/18xx/rules_difference_list/5_3.htm
>
> Indeed, I wonder if 'route specification' isn't the extent of 'automatic
> route calculation' that would be /allowed/, in a conventional,
> tournament-level 18xx game.  (I would expect that many 18xx experts feel
> calculating earnings properly is part of the game- not something that's
> necessarily /desirable/ to automate?)

That is similar to the question of open/closed money. For me revenue 
calculation sometimes is simply annoying, especially in late ORs late at 
night.
But for others it might be the essential skill of a good 18xx player... 
I admit it is not a particular strength in my own skillset.

>
> Will automated route calculation be offered as an option?  If users /don't/
> select automatic route calculation, will they still get some of the
> benefits of this work?  (Eg, specifically, for route-specification?)

Current status:
An optimal route is automatically calculated and suggested to the player.

But there will be an option for the next release. 
There could be the following settings:
-> strict (the value is enforced, player can only decide on distribution)
-> optional (suggests a value, which can be changed or confirmed)
-> off
Should there be a possibility to turn it on later in the game?
I would love an automatic mode: play the game to the end by running maximum 
and payout for all companies.

>
> Ideally, players could can still outline their own route(s), per-train, in
> the map view- Rails would then record that, and add-up/record the
> corresponding earnings precisely.  (And, of course- other users could
> review the earnings/routes, in the game history.)

Earnings figures are already recorded. I currently do not plan to implement 
the possibility of sketching routes manually.

Aliza Panitz wrote 2010-03-24:
> (1) Have a button that users can click to highlight every bit of track
> that their trains can reach from their tokens.  This will be useful
> even without route calculation, though it will require Rails to learn
> about track, routes, tokens, etc.
>
> The algorithm I'm thinking of would be a simple flood-fill that gets
> blocked by foreign tokens if the circles are filled.
>
> As a second stage it could limit itself to the length of the longest
> train the company has, though the flood-fill is useful even with
> imaginary infinite-length Diesels for showing where tokens can legally
> be placed.

The idea is similar to  the current implementation that possible extensions 
and token locations are highlighted. You suggest that it should be active 
only after player requesting it: In that sense it would be something like 
a "Hint" button. Is that something players would prefer to an always on/off 
option?

Stefan

[Rails-devel] Several answers related to revenue calculation

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

Hi Alex,
answers to several raised question in various e-mails.

And btw: 
The calculation class (RevenueCalculator) is plain Java 1.0 and depends on no 
other class (neither Java API, nor JGraph, nor Rails), except the 
RevenueAdapter to allow callbacks for intermediate revenue updates.

Also the data structure is strongly simplified, vertexes, edges and trains are 
stored as their required attributes in int / boolean arrays.

All the setup is down by the  RevenueAdapter.

In fact the process is that first from the Rails classes the already more 
generic classes NetworkVertex, NetworkEdge and NetworkTrain are generated.
Those are then used to populate the arrays of the RevenueCalculator.

Simply check the latest version at:
http://rails.cvs.sourceforge.net/viewvc/rails/18xx/rails/algorithms/RevenueCalculator.java

Stefan

> Yeah, I even can construct a case with 4D and 5 train in 18AL where it's
> better to run 4D only instead of running both trains. I need to add "null"
> route into consideration. Stefan, would you implementation be affected by
> the same issue?

That is not an issue for my implementation: A route can merely exist on a 
route to the start token only. However the route is considered of value zero, 
unless two stations are included. Steve Undy raised a similar question:

> BTW, in my trying out the CVS version I saw the route calculation running
> "excess" trains with a route including just one city.
>

Currently the route printout does not adjust the value of each station to the 
actual value. This effects express trains and double trains as well.

> I think that I have identical procedure, but when you say you evaluate
> train set at (4), and let's say you have 2 trains, does it increase
> evaluation count by 1 or by 2? I count it as 2 evaluations. In practice I
> keep results of evaluation of the first train while trying possible routes
> for the second train.

I changed my code somewhat that changed all of the numbers a little (at least 
with revenue calculation). It could have changed the number of the brute 
force approach, as I believe I removed one optimization, which would not work 
anymore if general bonus/malus rules are included.

> I've investigated number of evaluations a bit, mostly looking into a
> single train case as it has few affecting factors. I've confirmed that all
> 5601 possible routes in 8 train scan are unique. However, there are only
> 2460 unique city sequences. Total number (5601) is greater because it's
> often possible to run exactly the same sequence of cities while using
> somewhat different track. Of course, neither number matches yours. Do you
> have any ideas about the cause of discrepancy?

To be more precise I only evaluate after running the last train and each 
evaluation is single counted, regardless of  the number of trains in the 
train set. My suggestion if we want to really find the difference in the 
counts to start with running a two and/or three train in scenario A, cases 
which are easier to enumerate manually.

> I believe I have both optimizations you mentioned. Just to be clear on (2)
> - for example, if the candidate route starts at the station and is 7
> cities long while only 6-trains are available it won't be evaluated, right?

Yes that is right.

Re: [Rails-devel] Route calculation validations

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

I will echo the compliments - this is a really great development.
Even those who would prefer that Rails not suggest revenue amounts
should benefit from the utility of this code, which will allow many
other features (restricting track and token placement for one) to be
developed.

--
Chris

Please consider the environment before printing this e-mail.



On Thu, Apr 22, 2010 at 1:15 PM, Stefan Frey (web.de)
<ste...@we...> wrote:
> Erik & Phil:
> thanks for the compliments.
> I want to pass a substantial part of that to Alex, without his example and
> ideas I would have even started trying.
> This reminds that still most work is ahead us, as nearly each 18xx
> has some subtle tricks in the revenue part too.
> Stefan
>
>
> On Wednesday 21 April 2010 20:51:05 Erik Vos wrote:
>> Stefan,
>>
>> I can only say that I'm very impressed with what you have achieved on route
>> awareness and revenue calculation.
>> I have tried a few cases and the results all seem correct to me. Great
>> work!
>>
>> Erik.
>>
>>
>
>> I'd just like to voice my opinion about how awesome this is and that I
>> wish I had the time and intelligence to contribute meaningfully!
>>
>> I'll do my part by thoroughly playtesting the resultant product!
>>
>> Phil
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Route calculation validations

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

Erik & Phil:
thanks for the compliments. 
I want to pass a substantial part of that to Alex, without his example and 
ideas I would have even started trying. 
This reminds that still most work is ahead us, as nearly each 18xx 
has some subtle tricks in the revenue part too.
Stefan


On Wednesday 21 April 2010 20:51:05 Erik Vos wrote:
> Stefan,
>
> I can only say that I'm very impressed with what you have achieved on route
> awareness and revenue calculation.
> I have tried a few cases and the results all seem correct to me. Great
> work!
>
> Erik.
>
>

> I'd just like to voice my opinion about how awesome this is and that I
> wish I had the time and intelligence to contribute meaningfully!
>
> I'll do my part by thoroughly playtesting the resultant product!
>
> Phil

Re: [Rails-devel] Bugs

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

...
start of OR1. I think this is caused by the (very old) 1835 start round
code, which does follow the processing pattern that has evolved since for
               ^^^
Should of course be: does *not* follow.

[Rails-devel] Bugs

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

Fixed several bugs, including:

- #2989355 1856 W&S token not free 
  (caused by too early closing of W&S)

- #2989440 1899 Priority deal not in right place after auction 
  (affects all 1830-style auctions). Fix may cause old saved files fail to
reload.

- #2990120 1856 No Token placed when THB floated.
  (fixed before).

- #2990413 1851 Train disappears. This related to the *last* 8-train; buying
it surfaced an error.
  I have also added an "unlimited trains" option to 1851. Although
Blackwater Station says that 8-trains are unlimited, the rules I have are
silent on this matter.

- 1835 Bayern incorrectly floated if not all blue privates have been sold
(reported by JDG). 
  This fix triggered some reorganization of the float detection code.
  The problems still aren't over: in such a case the game now hangs at the
start of OR1. I think this is caused by the (very old) 1835 start round
code, which does follow the processing pattern that has evolved since for
stock and operating rounds. Fixing that will need more time. For now I would
urge 1835 playtesters to make sure that the whole start package is sold
before OR1.

Erik
  

Re: [Rails-devel] Route calculation validations

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

Stefan,

I can only say that I'm very impressed with what you have achieved on route
awareness and revenue calculation. 
I have tried a few cases and the results all seem correct to me. Great work!

Erik.


-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Wednesday 21 April 2010 00:11
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Route calculation validations

Another milestone for revenue calculation:
The found runs are shown on the Rail map.

Colors and strokes are currently defined in the HexMap class.
Undo and scaling is not yet supported.

As an example I have attached the Diesel run on Scenario A.
Stefan

Re: [Rails-devel] Route calculation validations

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

I think that I have identical procedure, but when you say you evaluate  
train set at (4), and let's say you have 2 trains, does it increase  
evaluation count by 1 or by 2? I count it as 2 evaluations. In practice I  
keep results of evaluation of the first train while trying possible routes  
for the second train.


On Tue, 20 Apr 2010 00:03:35 -0600, Stefan Frey <ste...@we...> wrote:

> Hi John,
> I believe that Alex already is considering another questions than you  
> raise:
>
> Yes we both optimize all trains simultaneously. To give a precise answer  
> my
> possible tree extensions at each station vertex are the following:
>
> 1) Traverse each edge to the neighbor vertex
> 2) If head train: start bottom train from start token
> 3) Start next (head) train
> 4) If vertex with value then evaluate train set
>
> Each head train starts at the virtual HQ to each of the available (start)
> tokens.
>
> This explains the huge increase in evaluations if two trains are run,  
> instead
> of one.
>
> 8 train alone:
> without prediction: 3.8k evaluations, 16.4k edges, time: < 1 sec
> with prediction: 62 evaluations, 858 predictions, 2.3k edges, < 1 sec
>
> 8 and 10 trains:
> without prediction: 1.9M evaluations, 11.0M edges, time: 90 sec
> with prediction: 25k evaluations, 143k predictions, 387k edges, time: 4  
> sec
>
> I can generate an example, where trains are run sub-length, if you are  
> still
> in doubt.
>
> Stefan
>
>
>>
>> I am just saying if you choose the best route for one train first, and  
>> then
>> find the best route for remaining trains, you won't find the optimal run
>> for all the trains.
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


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

Re: [Rails-devel] Route calculation validations

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

On Mon, 19 Apr 2010 23:50:51 -0600, John A. Tamplin <ja...@ja...> wrote:

> On Tue, Apr 20, 2010 at 1:32 AM, alexti <al...@sh...> wrote:
>
>> Considering that both trains are identical, how the order in which they
>> are iterated over would matter? Assuming we're talking about brute force
>> algorithm I believe that you're thinking about something else (not the
>> effects of the train iteration order). But let me elaborate on my
>> reasoning.
>>
>
> I am just saying if you choose the best route for one train first, and  
> then
> find the best route for remaining trains, you won't find the optimal run  
> for
> all the trains.
That's correct. That's why we have to iterate over the trains - I wish we  
didn't have to, but I don't see any way to avoid it.

>> However, your comment brings an interesting point: let's say we still  
>> have
>> the same example, but now we have 3 trains: one 3 and two 2s.
>> Longest-to-shortest order will result in 3 and 2 being used and
>> shortest-to-longest in 2 and 2 being used. And in both cases alternative
>> option (2+2 instead of 3+2 and vica versa) won't even be attempted. The
>> reason for that is that I don't consider 'null' route a route. To have
>> complete scan I would need to simply eliminate a train and find the
>> optimal solution with the remaining trains. I wonder if this matters in
>> any existing 18xx. But, after reading recent design discussion about  
>> train
>> obsolescence, I realize that this may actually matter if an obsolete  
>> train
>> has reduced revenue. That means that in the example above running 3+2 on
>> the exactly same route set might be better than 2+2.
>
>
> Similar issues apply in games where only certain types of trains get  
> certain
> bonuses (and in fact you might have the two trains left get different
> bonuses for different stops).
Yeah, I even can construct a case with 4D and 5 train in 18AL where it's  
better to run 4D only instead of running both trains. I need to add "null"  
route into consideration. Stefan, would you implementation be affected by  
the same issue?

Re: [Rails-devel] Route calculation validations

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

Really?

OK, I looked closer in better lighting and I see that it is pale pink
and pale peach.  If you go live with this, you gotta choose
contrasting colors.

Great work, by the way.

--
Chris

Please consider the environment before printing this e-mail.



On Tue, Apr 20, 2010 at 5:35 PM, Steve Undy <ste...@gm...> wrote:
> I see three different colors.
>
> BTW, in my trying out the CVS version I saw the route calculation running
> "excess" trains with a route including just one city.
>
> Steve Undy
> st...@ro...
>
>
> On Tue, Apr 20, 2010 at 6:07 PM, Chris Shaffer <chr...@gm...>
> wrote:
>>
>> The image shows three trains running but only two colors of
>> highlighting.  Why are both trains running F9-G10 and G10-G12 the same
>> color?  Shouldn't there be three colors?
>>
>> --
>> Chris
>>
>> Please consider the environment before printing this e-mail.
>>
>>
>>
>> On Tue, Apr 20, 2010 at 3:14 PM, Stefan Frey (web.de)
>> <ste...@we...> wrote:
>> > And using the new route display allows to give the simple example on a
>> > 1889
>> > map, that hopefully answers the question below.
>> > The TR has  4, 3, 3 trains, but each of them is cut down to run as a 2
>> > train.
>> > The same happens for the IR later that round.
>> >
>> > Stefan
>> >
>> > On Tuesday 20 April 2010 07:50:51 John A. Tamplin wrote:
>> >> I am just saying if you choose the best route for one train first, and
>> >> then
>> >> find the best route for remaining trains, you won't find the optimal
>> >> run
>> >> for all the trains.
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > 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] Route calculation validations

[Steve U. <ste...@gm...>]

I see three different colors.

BTW, in my trying out the CVS version I saw the route calculation running
"excess" trains with a route including just one city.

Steve Undy
st...@ro...


On Tue, Apr 20, 2010 at 6:07 PM, Chris Shaffer <chr...@gm...>wrote:

> The image shows three trains running but only two colors of
> highlighting.  Why are both trains running F9-G10 and G10-G12 the same
> color?  Shouldn't there be three colors?
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
>
> On Tue, Apr 20, 2010 at 3:14 PM, Stefan Frey (web.de)
> <ste...@we...> wrote:
> > And using the new route display allows to give the simple example on a
> 1889
> > map, that hopefully answers the question below.
> > The TR has  4, 3, 3 trains, but each of them is cut down to run as a 2
> train.
> > The same happens for the IR later that round.
> >
> > Stefan
> >
> > On Tuesday 20 April 2010 07:50:51 John A. Tamplin wrote:
> >> I am just saying if you choose the best route for one train first, and
> then
> >> find the best route for remaining trains, you won't find the optimal run
> >> for all the trains.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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] Route calculation validations

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

The image shows three trains running but only two colors of
highlighting.  Why are both trains running F9-G10 and G10-G12 the same
color?  Shouldn't there be three colors?

--
Chris

Please consider the environment before printing this e-mail.



On Tue, Apr 20, 2010 at 3:14 PM, Stefan Frey (web.de)
<ste...@we...> wrote:
> And using the new route display allows to give the simple example on a 1889
> map, that hopefully answers the question below.
> The TR has  4, 3, 3 trains, but each of them is cut down to run as a 2 train.
> The same happens for the IR later that round.
>
> Stefan
>
> On Tuesday 20 April 2010 07:50:51 John A. Tamplin wrote:
>> I am just saying if you choose the best route for one train first, and then
>> find the best route for remaining trains, you won't find the optimal run
>> for all the trains.
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Route calculation validations

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

I'd just like to voice my opinion about how awesome this is and that I
wish I had the time and intelligence to contribute meaningfully!

I'll do my part by thoroughly playtesting the resultant product!

Phil

On 20 April 2010 23:10, Stefan Frey (web.de) <ste...@we...> wrote:
> Another milestone for revenue calculation:
> The found runs are shown on the Rail map.
>
> Colors and strokes are currently defined in the HexMap class.
> Undo and scaling is not yet supported.
>
> As an example I have attached the Diesel run on Scenario A.
> Stefan
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Route calculation validations

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

And using the new route display allows to give the simple example on a 1889 
map, that hopefully answers the question below.
The TR has  4, 3, 3 trains, but each of them is cut down to run as a 2 train. 
The same happens for the IR later that round.
 
Stefan

On Tuesday 20 April 2010 07:50:51 John A. Tamplin wrote:
> I am just saying if you choose the best route for one train first, and then
> find the best route for remaining trains, you won't find the optimal run
> for all the trains.

Re: [Rails-devel] Route calculation validations

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

Another milestone for revenue calculation:
The found runs are shown on the Rail map.

Colors and strokes are currently defined in the HexMap class.
Undo and scaling is not yet supported.

As an example I have attached the Diesel run on Scenario A.
Stefan

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

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

Erik:
I forgot to answer your implicit close private comment: 
There is already a Close Private action implemented: I currently monitor 
potential tile/token lay closures for the noMap mode, but I had already in 
mind to change that to a closeManually option for a PrivateCompany (which 
coule be activated by the NoMap game optioin.) I will implement that next 
week and I assume you need that for the Ostbayern and Pfalz(?).
Stefan


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

Re: [Rails-devel] Priority deal not in right place after auction in1889 - ID: 2989440

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

As long as things are communicated appropriately to the user base I
don't see it being a problem.  If the patch notes state that existing
save files will be incompatible and that is made known in the
announcement then I think that is sufficient warning for most people

Phil

On 20 April 2010 20:23, Erik Vos <eri...@xs...> wrote:
> Well, bugs must be fixed, regardless, in my opinion.
> I have done it, and the fix seems to work. Can you please doublecheck?
>
> There are more reasons why certain files will be rendered invalid with the
> next release, I'm afraid we'll have to bite the bullet.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Monday 19 April 2010 23:56
> To: Development game
> Subject: [Rails-devel] Priority deal not in right place after auction in1889
> - ID: 2989440
>
> Erik:
> this problem effects all games using StartRound_1830.
> Fixing it potentially makes a lot of game files invalid ( all that have an
> auction started during the start round, unless the passing player is the
> player who is the next after the last buyer).
> What do you think?
> Stefan
>
> ----------------------------------------------------------------------------
> --
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Priority deal not in right place after auction in1889 - ID: 2989440

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

Well, bugs must be fixed, regardless, in my opinion.
I have done it, and the fix seems to work. Can you please doublecheck? 

There are more reasons why certain files will be rendered invalid with the
next release, I'm afraid we'll have to bite the bullet.

Erik.

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Monday 19 April 2010 23:56
To: Development game
Subject: [Rails-devel] Priority deal not in right place after auction in1889
- ID: 2989440

Erik:
this problem effects all games using StartRound_1830. 
Fixing it potentially makes a lot of game files invalid ( all that have an 
auction started during the start round, unless the passing player is the 
player who is the next after the last buyer).
What do you think?
Stefan

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

Re: [Rails-devel] Route calculation validations

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

Hi John,
I believe that Alex already is considering another questions than you raise:

Yes we both optimize all trains simultaneously. To give a precise answer my 
possible tree extensions at each station vertex are the following:

1) Traverse each edge to the neighbor vertex
2) If head train: start bottom train from start token
3) Start next (head) train
4) If vertex with value then evaluate train set

Each head train starts at the virtual HQ to each of the available (start) 
tokens.

This explains the huge increase in evaluations if two trains are run, instead 
of one.

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

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

I can generate an example, where trains are run sub-length, if you are still 
in doubt.

Stefan


>
> I am just saying if you choose the best route for one train first, and then
> find the best route for remaining trains, you won't find the optimal run
> for all the trains.
>

Re: [Rails-devel] Route calculation validations

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

On Tue, Apr 20, 2010 at 1:32 AM, alexti <al...@sh...> wrote:

> Considering that both trains are identical, how the order in which they
> are iterated over would matter? Assuming we're talking about brute force
> algorithm I believe that you're thinking about something else (not the
> effects of the train iteration order). But let me elaborate on my
> reasoning.
>

I am just saying if you choose the best route for one train first, and then
find the best route for remaining trains, you won't find the optimal run for
all the trains.


> However, your comment brings an interesting point: let's say we still have
> the same example, but now we have 3 trains: one 3 and two 2s.
> Longest-to-shortest order will result in 3 and 2 being used and
> shortest-to-longest in 2 and 2 being used. And in both cases alternative
> option (2+2 instead of 3+2 and vica versa) won't even be attempted. The
> reason for that is that I don't consider 'null' route a route. To have
> complete scan I would need to simply eliminate a train and find the
> optimal solution with the remaining trains. I wonder if this matters in
> any existing 18xx. But, after reading recent design discussion about train
> obsolescence, I realize that this may actually matter if an obsolete train
> has reduced revenue. That means that in the example above running 3+2 on
> the exactly same route set might be better than 2+2.


Similar issues apply in games where only certain types of trains get certain
bonuses (and in fact you might have the two trains left get different
bonuses for different stops).

-- 
John A. Tamplin

Re: [Rails-devel] Route calculation validations

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

On Mon, 19 Apr 2010 23:07:46 -0600, John A. Tamplin <ja...@ja...> wrote:

> On Tue, Apr 20, 2010 at 12:49 AM, alexti <al...@sh...> wrote:
>
>> Btw, in what order do you iterate over trains? I go from longest to
>> shortest. On some earlier tests I've decided that it worked better, but
>> now I wonder if the diesel case might be an exception...
>>
>
> Do you backtrack after choosing a route for the larger train?  If not,  
> then
> it seems you aren't going to get optimal routes, since in many cases the
> optimal run for a group of trains is not optimal for any one of them.   
> As a
> simple example consider two 3 trains running on A-B-C, where the only  
> token
> is in B.  Clearly the best run is A-B and B-C, which is not optimal for
> either 3 train.  This particular example, or a variation of it, comes up
> *very* often in early games.
Considering that both trains are identical, how the order in which they  
are iterated over would matter? Assuming we're talking about brute force  
algorithm I believe that you're thinking about something else (not the  
effects of the train iteration order). But let me elaborate on my  
reasoning.

Let's consider the case of 3 and 2 trains. If we start the iteration from  
3 train, the first attempt will be made to apply it to the route B-C (in  
my algorithm, but any brute force algorithm will eventually get to this  
B-C route). After eliminating this route from the graph, the remaining  
graph A-B will contain only one route which will be assigned to 2-train.  
Exactly the same will happen in the case of shortest-to-longest iteration  
order. So, no matter, what is the train iteration order, every route  
combination will get evaluated. However, the performance may vary  
depending on whether the inner loop runs over larger or smaller graph. If  
there are several route sets with identical values, it may also lead to  
different route set being selected.

However, your comment brings an interesting point: let's say we still have  
the same example, but now we have 3 trains: one 3 and two 2s.  
Longest-to-shortest order will result in 3 and 2 being used and  
shortest-to-longest in 2 and 2 being used. And in both cases alternative  
option (2+2 instead of 3+2 and vica versa) won't even be attempted. The  
reason for that is that I don't consider 'null' route a route. To have  
complete scan I would need to simply eliminate a train and find the  
optimal solution with the remaining trains. I wonder if this matters in  
any existing 18xx. But, after reading recent design discussion about train  
obsolescence, I realize that this may actually matter if an obsolete train  
has reduced revenue. That means that in the example above running 3+2 on  
the exactly same route set might be better than 2+2.

Re: [Rails-devel] Route calculation validations

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

I've figured I could do a quick experiment and change the order of train  
iteration. So here are new results:
8+10 - 3649121, 4.5s
8+D - 16097719, 22.7s

8+D case is much faster now and 8+10 is slightly faster. I am not sure I  
understand this result - number of evaluations is nearly identical (I am  
not entirely sure if it's supposed to be identical or not and anyway I  
don't trust my ability to calculate each route only once :) ). So why the  
time went down? Besides, I expected this swap to improve diesel case, but  
8+10 being faster than 10+8 surprises me...



On Mon, 19 Apr 2010 22:49:51 -0600, alexti <al...@sh...> wrote:

> Hi Stefan,
>
> Here are my numbers. It's pointless to compare edges, because I'm using
> 2-phased approach, so I'm only giving number of revenue evaluations. I
> also assume that you're talking about 10+8 when you say "10+6" (that  
> seems
> obvious from the attached stats). The good news is that the optimal
> revenue we're getting is identical in all cases. The bad news is that
> everything else is different. I have much higher number of revenue
> evaluation. I suspect that I evaluate something unnecessary (considering
> that I never find any better route :) ). That's not necessarily bad -
> perhaps if I get rid of it I can compute things faster. It's interesting
> that none of our methods is good for diesel plus other train. What's
> worse, I think that this time can deteriorate dramatically on the  
> examples
> with more cities. The root of the problem is that there might be a lot of
> different diesel routes with very small value variation (like within
> 10-30$) which would mean that in each case the remaining graph will have
> to be evaluated for the 8 train...
>
> Btw, in what order do you iterate over trains? I go from longest to
> shortest. On some earlier tests I've decided that it worked better, but
> now I wonder if the diesel case might be an exception...
>
> 8 - 5601, 0.003s
> D - 957676, 1.4s
>
> 10+8 - 3649238, 5.8s
> D+8 - 16110745, 74.5s
>
> Thanks,
> Alex.
>
>
>
> On Mon, 19 Apr 2010 14:01:14 -0600, Stefan Frey <ste...@we...>  
> wrote:
>
>> Hi Alex,
>> I have attached a document that contains the detailed numbers for  
>> several
>> train combinations without and with the revenue prediction active.
>>
>> The following figures are defined:
>> revenue evaluation: how often the revenue of all trains is evaluated
>> edges travelled: how many edges were followed during the search
>> predictions: how often the potential maximum revenue was predicted.
>>
>> My desktop is even slower as my laptop, as it is slightly older and has
>> an AMD
>> processor.
>>
>> It clearly shows that revenue predictions is strongest for train
>> combinations
>> and non-diesel trains. Running a diesel alone is not any faster, unless
>> an
>> optimal solution is found (early).
>>
>> Stefan
>>
>> I sent that to the develop list, as others might also be interested in
>> those
>> numbers. I extract the main figures below,
>> all runs on the test scenario A.
>>
>> 8 train alone:
>> without prediction: 3.8k evaluations, 16.4k edges, time: < 1 sec
>> with prediction: 62 evaluations, 858 predictions, 2.3k edges, < 1 sec
>>
>> 8 and 10 trains:
>> without prediction: 1.9M evaluations, 11.0M edges, time: 90 sec
>> with prediction: 25k evaluations, 143k predictions, 387k edges, time: 4
>> sec
>>
>> This clearly shows the strong increase of possible solutions, if more
>> than one
>> train is involved. It is around 1:500!
>>
>> Diesel train:
>> without prediction: 424k evaluations, 3.3M edges, time: 25 sec
>> with prediction: 335k evaluations, 753k predictions, 2.6M edges, time:
>> 23 sec
>> (In this example an optimal solution is found, but late).
>>
>> A diesel is less complicated than the combination of an 8 and 10, but  
>> the
>> revenue prediction does no help.
>>
>> Diesel and a 6 train:
>> without prediction: 7.3M evaluations, 52.5M edges, time: 480 sec
>> with prediction: 231k evaluations, 2.8M predictions, 6.2M edges, time:
>> 56 sec
>>
>> Adding a 6 train, increases the running time by 20 without prediction,
>> but
>> only a little more than doubles with prediction.
>>
>>
>>
>> On Sunday 18 April 2010 17:44:04 you wrote:
>>> Hi Stefan,
>>>
>>> I would agree about the name of the first number.
>>>
>>> (1) should be ok, I do the same, and there is no good reason for the
>>> algorithm to try evaluating route that just extend already evaluated
>>> route
>>> by some stations the train can't reach anyway. Or we could run the test
>>> on
>>> "express" train that can skip anything. Express trains (or any train
>>> capable of skipping cities) actually make me wonder what are possible
>>> rules about visiting the same hex. In some games train is not allowed  
>>> to
>>> visit the same hex twice (when there are 2 separate cities on the  
>>> tile).
>>> If there is any game with this rule and with express trains, then
>>> there's
>>> a question - if the train skips one city in the hex and counts another  
>>> -
>>> is it valid route?
>>>
>>> (2) I apply the same method to the routes, but I didn't evaluate "half"
>>> routes - I only evaluate complete route (consisting of those 2 parts).
>>> How
>>> can you do differently? - There might be bonus for visiting 2 cities in
>>> different halves, or something like east-west run.
>>>
>>> If it's difficult to extract this number from your code now, we could
>>> set
>>> up example with the station in the dead-end, so there's only one way to
>>> leave it.
>>>
>>> Number of segments is relevant to the two-phased approach only. It is
>>> number of edges in the "coarse" graph (which is the same as number of
>>> distinct ways to travel between any pair of cities). You were asking
>>> about
>>> this number earlier to evaluate amount of memory that would need to be
>>> stored.
>>>
>>> I've also done profiling and it appears that storing segment exclusions
>>> as
>>> a vector of segments excluded by each segment is fine - this is not a
>>> bottleneck. So I haven't tried 2D array of booleans approach. But maybe
>>> I
>>> should try some different cases (for example set of 4 trains (2,2,3 and
>>> 3)
>>> - that may have a bottleneck in different places comparing to the case
>>> of
>>> few long trains).
>>>
>>> Thanks,
>>> Alex.
>>>
>>> On Sun, 18 Apr 2010 13:28:24 -0600, Stefan Frey <ste...@we...>
>>> wrote:
>>> > Hi Alex,
>>> > I would call the first statistic "number of  route evaluations" and  
>>> it
>>> > counts
>>> > every call to the evaluation function. This figure is also available
>>> for
>>> > multiple-train runs. If we have the same number, it is almost sure
>>> that
>>> > the
>>> > two algorithms work identical. If not, it proves nothing, see below.
>>> >
>>> > Potential problems:
>>> > 1) I terminate trains as soon as possible, thus numbers depend on the
>>> > sequence
>>> > of vertexes visited.
>>> >
>>> > 2) I have train runs divided in two half trains: First the head train
>>> > starts
>>> > and each station the train can return to its start token and then the
>>> > bottom
>>> > train runs. To avoid duplication of routes (due to symmetry) the
>>> bottom
>>> > train
>>> > can only start to the side with increased orientation. If I remember
>>> > that is
>>> > a different approach to yours.
>>> >
>>> > So if we want to compare figures we have to run a train with infinite
>>> > length
>>> > (to avoid termination) and is not allowed to run twice from the start
>>> > vertex.
>>> >
>>> > I will have to adjust my codes to accommodate for such a test.
>>> >
>>> > The other statistic I am not fully clear about: Wat is exactly the
>>> > number of
>>> > segments? If this is related to the two-phase approach I assume this
>>> is
>>> > the
>>> > maximum number of connections between two stations on the map?
>>> > And I guess, that this might be the answer to the unrelated question  
>>> I
>>> > raised
>>> > before. This strengthens the case of your approach. I will implement
>>> it
>>> > as
>>> > soon as I have some time left, which will be most likely after the
>>> next
>>> > release.
>>> >
>>> > Stefan
>>> >
>>> > On Sunday 18 April 2010 06:34:51 you wrote:
>>> >> Hi Stefan,
>>> >>
>>> >> I thought it might be useful to compare how many routes we try  
>>> during
>>> >> the
>>> >> complete route search. We should be getting the same number. If we
>>> are
>>> >> not
>>> >> it will indicate that one of us (or both) have a bug. I suppose to
>>> test
>>> >> it
>>> >> we would need to run a single sufficiently long train (or maybe try
>>> for
>>> >> various train lengths) on the same track.
>>> >>
>>> >> I've also checked on number of segments in two-phased approach. In
>>> the
>>> >> scenario B there are just 153 segments.
>>> >>
>>> >> Thanks,
>>> >> Alex.
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


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

Re: [Rails-devel] Route calculation validations

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

On Tue, Apr 20, 2010 at 12:49 AM, alexti <al...@sh...> wrote:

> Btw, in what order do you iterate over trains? I go from longest to
> shortest. On some earlier tests I've decided that it worked better, but
> now I wonder if the diesel case might be an exception...
>

Do you backtrack after choosing a route for the larger train?  If not, then
it seems you aren't going to get optimal routes, since in many cases the
optimal run for a group of trains is not optimal for any one of them.  As a
simple example consider two 3 trains running on A-B-C, where the only token
is in B.  Clearly the best run is A-B and B-C, which is not optimal for
either 3 train.  This particular example, or a variation of it, comes up
*very* often in early games.

-- 
John A. Tamplin

Re: [Rails-devel] Route calculation validations

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

Hi Stefan,

Here are my numbers. It's pointless to compare edges, because I'm using  
2-phased approach, so I'm only giving number of revenue evaluations. I  
also assume that you're talking about 10+8 when you say "10+6" (that seems  
obvious from the attached stats). The good news is that the optimal  
revenue we're getting is identical in all cases. The bad news is that  
everything else is different. I have much higher number of revenue  
evaluation. I suspect that I evaluate something unnecessary (considering  
that I never find any better route :) ). That's not necessarily bad -  
perhaps if I get rid of it I can compute things faster. It's interesting  
that none of our methods is good for diesel plus other train. What's  
worse, I think that this time can deteriorate dramatically on the examples  
with more cities. The root of the problem is that there might be a lot of  
different diesel routes with very small value variation (like within  
10-30$) which would mean that in each case the remaining graph will have  
to be evaluated for the 8 train...

Btw, in what order do you iterate over trains? I go from longest to  
shortest. On some earlier tests I've decided that it worked better, but  
now I wonder if the diesel case might be an exception...

8 - 5601, 0.003s
D - 957676, 1.4s

10+8 - 3649238, 5.8s
D+8 - 16110745, 74.5s

Thanks,
Alex.



On Mon, 19 Apr 2010 14:01:14 -0600, Stefan Frey <ste...@we...> wrote:

> Hi Alex,
> I have attached a document that contains the detailed numbers for several
> train combinations without and with the revenue prediction active.
>
> The following figures are defined:
> revenue evaluation: how often the revenue of all trains is evaluated
> edges travelled: how many edges were followed during the search
> predictions: how often the potential maximum revenue was predicted.
>
> My desktop is even slower as my laptop, as it is slightly older and has  
> an AMD
> processor.
>
> It clearly shows that revenue predictions is strongest for train  
> combinations
> and non-diesel trains. Running a diesel alone is not any faster, unless  
> an
> optimal solution is found (early).
>
> Stefan
>
> I sent that to the develop list, as others might also be interested in  
> those
> numbers. I extract the main figures below,
> all runs on the test scenario A.
>
> 8 train alone:
> without prediction: 3.8k evaluations, 16.4k edges, time: < 1 sec
> with prediction: 62 evaluations, 858 predictions, 2.3k edges, < 1 sec
>
> 8 and 10 trains:
> without prediction: 1.9M evaluations, 11.0M edges, time: 90 sec
> with prediction: 25k evaluations, 143k predictions, 387k edges, time: 4  
> sec
>
> This clearly shows the strong increase of possible solutions, if more  
> than one
> train is involved. It is around 1:500!
>
> Diesel train:
> without prediction: 424k evaluations, 3.3M edges, time: 25 sec
> with prediction: 335k evaluations, 753k predictions, 2.6M edges, time:  
> 23 sec
> (In this example an optimal solution is found, but late).
>
> A diesel is less complicated than the combination of an 8 and 10, but the
> revenue prediction does no help.
>
> Diesel and a 6 train:
> without prediction: 7.3M evaluations, 52.5M edges, time: 480 sec
> with prediction: 231k evaluations, 2.8M predictions, 6.2M edges, time:  
> 56 sec
>
> Adding a 6 train, increases the running time by 20 without prediction,  
> but
> only a little more than doubles with prediction.
>
>
>
> On Sunday 18 April 2010 17:44:04 you wrote:
>> Hi Stefan,
>>
>> I would agree about the name of the first number.
>>
>> (1) should be ok, I do the same, and there is no good reason for the
>> algorithm to try evaluating route that just extend already evaluated  
>> route
>> by some stations the train can't reach anyway. Or we could run the test  
>> on
>> "express" train that can skip anything. Express trains (or any train
>> capable of skipping cities) actually make me wonder what are possible
>> rules about visiting the same hex. In some games train is not allowed to
>> visit the same hex twice (when there are 2 separate cities on the tile).
>> If there is any game with this rule and with express trains, then  
>> there's
>> a question - if the train skips one city in the hex and counts another -
>> is it valid route?
>>
>> (2) I apply the same method to the routes, but I didn't evaluate "half"
>> routes - I only evaluate complete route (consisting of those 2 parts).  
>> How
>> can you do differently? - There might be bonus for visiting 2 cities in
>> different halves, or something like east-west run.
>>
>> If it's difficult to extract this number from your code now, we could  
>> set
>> up example with the station in the dead-end, so there's only one way to
>> leave it.
>>
>> Number of segments is relevant to the two-phased approach only. It is
>> number of edges in the "coarse" graph (which is the same as number of
>> distinct ways to travel between any pair of cities). You were asking  
>> about
>> this number earlier to evaluate amount of memory that would need to be
>> stored.
>>
>> I've also done profiling and it appears that storing segment exclusions  
>> as
>> a vector of segments excluded by each segment is fine - this is not a
>> bottleneck. So I haven't tried 2D array of booleans approach. But maybe  
>> I
>> should try some different cases (for example set of 4 trains (2,2,3 and  
>> 3)
>> - that may have a bottleneck in different places comparing to the case  
>> of
>> few long trains).
>>
>> Thanks,
>> Alex.
>>
>> On Sun, 18 Apr 2010 13:28:24 -0600, Stefan Frey <ste...@we...>  
>> wrote:
>> > Hi Alex,
>> > I would call the first statistic "number of  route evaluations" and it
>> > counts
>> > every call to the evaluation function. This figure is also available  
>> for
>> > multiple-train runs. If we have the same number, it is almost sure  
>> that
>> > the
>> > two algorithms work identical. If not, it proves nothing, see below.
>> >
>> > Potential problems:
>> > 1) I terminate trains as soon as possible, thus numbers depend on the
>> > sequence
>> > of vertexes visited.
>> >
>> > 2) I have train runs divided in two half trains: First the head train
>> > starts
>> > and each station the train can return to its start token and then the
>> > bottom
>> > train runs. To avoid duplication of routes (due to symmetry) the  
>> bottom
>> > train
>> > can only start to the side with increased orientation. If I remember
>> > that is
>> > a different approach to yours.
>> >
>> > So if we want to compare figures we have to run a train with infinite
>> > length
>> > (to avoid termination) and is not allowed to run twice from the start
>> > vertex.
>> >
>> > I will have to adjust my codes to accommodate for such a test.
>> >
>> > The other statistic I am not fully clear about: Wat is exactly the
>> > number of
>> > segments? If this is related to the two-phase approach I assume this  
>> is
>> > the
>> > maximum number of connections between two stations on the map?
>> > And I guess, that this might be the answer to the unrelated question I
>> > raised
>> > before. This strengthens the case of your approach. I will implement  
>> it
>> > as
>> > soon as I have some time left, which will be most likely after the  
>> next
>> > release.
>> >
>> > Stefan
>> >
>> > On Sunday 18 April 2010 06:34:51 you wrote:
>> >> Hi Stefan,
>> >>
>> >> I thought it might be useful to compare how many routes we try during
>> >> the
>> >> complete route search. We should be getting the same number. If we  
>> are
>> >> not
>> >> it will indicate that one of us (or both) have a bug. I suppose to  
>> test
>> >> it
>> >> we would need to run a single sufficiently long train (or maybe try  
>> for
>> >> various train lengths) on the same track.
>> >>
>> >> I've also checked on number of segments in two-phased approach. In  
>> the
>> >> scenario B there are just 153 segments.
>> >>
>> >> Thanks,
>> >> Alex.
>

[Rails-devel] Priority deal not in right place after auction in 1889 - ID: 2989440

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

Erik:
this problem effects all games using StartRound_1830. 
Fixing it potentially makes a lot of game files invalid ( all that have an 
auction started during the start round, unless the passing player is the 
player who is the next after the last buyer).
What do you think?
Stefan