Re: [Rails-devel] Route calculation for huge runs

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

As mentioned earlier I had started making my way down to open issues in my 
Rails mail archive, so this mail is from March 2011.

The scenario Aliza mentions is pretty extreme (three D trains for a company 
with 10 tokens) and to my knowledge this is only possible for 1856. 
So in fact my surprise was on the positive side that Rails DID actually came 
up with the final result instead of running forever.

In my tests a pure brute-force search usually already  does not finish in 
reasonable time for double D combinations on similar networks. I will focus on 
the technical details in a response to John Tamplin's reply.

This mail is a reply to Aliza's suggestions on improving the UI behavior.

> when Rails is still calculating a run, there
> should be a note on the screen saying something like "route
> calculation in progress."

This can be done. However I would only display the message if a minimum time 
elapsed (for example 5 seconds).

> The next thing is that I'd like to know what was autocalculated versus
> hand-entered.  A note in the logfile saying what the calculated run
> was would be very useful. (Yes, I could go back in the history and
> look for myself, but that's not always feasible.)

Adding this information is possible. 
(I understand "logfile" here as the game report shown in the UI and not the 
18xx.log which is written by Rails, where this information and many more is 
already included).

However I am strongly interested in your (and all others) experience if and 
how often the experienced that situation: 

As the current algorithm (in theory) guarantees the correct solution, any 
deviation between the calculated result and the correct result should be filed 
as a bug with according save file.

Bugs (especially for example in tile definitions and the code for 
initialization and optimization before the revenue calculation, which exceeds 
the code for the core algorithm by factor 10 at least) can never be ruled out, 
so please report any observed differences.

> Finally, any interrupt between calculating a run and entering it
> restarts the calculation -- even things like saving the file or
> entering the destination of another company.  Highly annoying, though
> not quite a bug.

I considered this solution: However the interruption could have changed 
anything that might have impact on the result.
For example: undo, place token. Thus I decided to restart in any case of 
interruption to be on the safe side.

Stefan

The complete mail:

On Saturday, March 12, 2011 10:02:04 pm Aliza Panitz wrote:
> (Note:  my example is a what-if run-forward of a current PbeM game.
> James, Jevon, Jerry, Breno, Scott, please go away.)
> 
> Rails 1.4.1, 1856, CGR running 3 Diesels. (This is not completely
> absurd -- my plausible choices for the CGR in this game are 5,6; D,5;
> and D,D,D.  The money doesn't work out right for D,D.  This is a very
> odd game where the CGR formed with 4,5,6, and ten excellent tokens)
> 
> At first, run calculations were taking 15-20 minutes on a T60 laptop
> running Windows XP.  Now, though, I've got a calculation that's been
> running for well over an hour, taking 45-55% of my CPU the whole time.
> The map isn't that much more developed! [added - it finally completed.
>  $1440 per 10% share.]
> 
> Earlier, I was all ready to file a Rails bug because I could clearly
> see a better route than what was displayed, but I stepped away from my
> computer and when I came back, a better run was shown instead.  So,
> one simple request:  when Rails is still calculating a run, there
> should be a note on the screen saying something like "route
> calculation in progress."  (Screen shot attached.  Even I can quickly
> see that the light blue train should run towards the WGB tokens for an
> extra $60 on the run, and in fact Rails eventually did $10 or $20
> better than that.)
> 
> The next thing is that I'd like to know what was autocalculated versus
> hand-entered.  A note in the logfile saying what the calculated run
> was would be very useful. (Yes, I could go back in the history and
> look for myself, but that's not always feasible.)
> 
> Finally, any interrupt between calculating a run and entering it
> restarts the calculation -- even things like saving the file or
> entering the destination of another company.  Highly annoying, though
> not quite a bug.