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

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

Alex, see comments below.

> By "stations" I meant the station markers (owned by companies). I thought
> it's more or less standard term (but now I realize that it might be just a
> local dialect). By "city" I meant cities and towns - basically any vertex
> with non-zero value.

In fact I allow any vertex to add value (no requirement for a minor/major 
station type), but I do not allow trains to terminate there. (That is not 
important for the games implemented so far, but think about the ferry bonus 
in 18Scan).

>
> I do the same, but when you reach dead-end, how do you remember what
> branch (and from what vertex) to try next?

As soon as a deadend is encountered (and after I started the bottom part and 
run other trains), I un-encounter the vertex and return the travelled edge. 
As the encounter calls are recursively the information is on the stack. 
The only need for my own stack of vertices and edges is to store the optimal 
run.

>
> I'm sure it's possible to construct scenarios when one method or another
> will be faster. I was wondering if one method is typically better than
> another in common scenarios. Btw, how do you deal with "exclusive" bonuses
> in this scenarios (for example, train chits in 18AL)?
>

You mean in the current implementation or with train dominance?
Currently simple bonuses are covered by the train-dependent vertex values, for 
the complex ones a boolean array controls if a bonus is active for a specific 
train.
Special train bonuses break train dominance, another reason not for 
implementing it.

>
> I agree in principle, but I suspect that our current prediction mechanism
> already eliminate most of such cases. If you used 10 train for a short
> route, there will be only so many ways to achieve the threshold with the
> remaining trains.

The scenarios where it excels compared to revenue predictions are those in 
which you cannot run the trains to the full length.

>
> I am also curious how much 2-phased approach would help your
> implementation - with your magic predictor you don't seem to spend much
> time scanning the routes anyway :)
>

I hope it is not too "magic", as it will most likely imply that there is 
something wrong. I will think about more tests to rule that out. Are you sure 
you have fully implemented the sequential approach of the revenue prediction 
for the trainset?

Stefan