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

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

Hi Stefan,

On Wed, 19 May 2010 15:08:24 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> 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).
Yes, I would have to create artificial vertex in this case (because I  
would remove all intermediate ones).

>> 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.
Oh, I see. That essentially means that you're using stack as a way to  
dynamically allocate memory. It probably means that function inlining is  
not working and the actual overhead may show up as a function call  
overhead. Anyway, that's something to look at in the profiler. I was  
hoping you've found some algorithm that was avoiding the need for dynamic  
memory management.

>> 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 was thinking about both. In particular, the situations when on a given  
route set some bonus can be applied to one of several trains and when  
there're some other bonuses possible (for example one train doubles the  
value of its run (including bonus) and another doesn't).

>> 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 not sure about that... If the optimal route set is achieved on 4+5  
routes, it wouldn't matter which one is served by 8 train and which one is  
by 10. I think it would only make difference on such scenarios where the  
optimal route sets contains routes that have length between the length of  
the trains (for example 6+9 routes for 8+10 trains).

>> 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?
No :-) But I can't find anything missing in my implementation. I wonder if  
we either misunderstand what each other counts or someones counting is  
wrong (though mine matching function call count shown by the profiler :) )


Alex.