rails-devel

[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] Several answers related to revenue calculation

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

Hi Stefan,

Thanks for the information. I agree that if we want to track down  
evaluation count differences it will be better to start from a single 2 or  
3 train run.

Alex.

On Thu, 22 Apr 2010 14:43:34 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> 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.
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/