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

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

Hi Stefan,

On Mon, 24 May 2010 15:50:14 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Hi Alex,
> answers/comments see below.
> Most of them delay a more detailed discussion for the time after the  
> current
> release.
> Stefan
>
>> 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.
>>
>
> In principle I could replace the reliance on the java stack mechanism by
> storing the local variables in own stack. The next step would be to  
> remove
> all recursive function calls, but I have doubts that this will improve  
> the
> speed substantially, if at all. I plan to install the TPFP plugin after  
> this
> release to get some data on that.
It certainly worth profiling before trying to change those things. Results  
may also differ depending on particular brand of JVM one is running...

>
>> > 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 was more referring that the revenue prediction improves with the train  
> run
> lengths in general, not that train dominance is better in those cases.
I agree with that.

> The good thing about revenue prediction is that if the network increases  
> it
> gets less likely that the trains runs are short. It is very unlikely for  
> a
> company to have a complex network AND not being able to run its trains  
> for a
> good length.
You haven't seen some of our local games ;-)
But in general it depends on the game, I think. Typical scenario when such  
things happen is when there's a single choke-point with 2-3 exits. This  
means that the train that passes through it effectively bisects the graph  
into to for the remaining trains. I had some ideas about dealing with such  
cases - looking at the graph and finding vertices such that removal of 2  
adjacent to them splits the graph. In this situation optimization over 2  
(or more) parts can be done somewhat independently.

Alex.