rails-devel

[Rails-devel] Experimental version of revenue calculation

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

There is a first working version for revenue calculation in CVS.
The interface is minimal and added to the graph view:

Thus in the ORWindow select Info => NetworkInfo and the 
public company. Then the graph is displayed and the optimal revenue result and
the vertexes run for each train for the result. 

After this one can add additional trains and the optimization restarts.

For available traintypes (currently default (including diesel), +, E and D 
trains) check the addTrainByString method in RevenueAdapter.

BE CAREFUL:
1) It generates a lot of debug in the 18xx.log if the logging level is set to 
DEBUG (as it is the default). If one tests complicated cases it can fill up 
the hd quite quickly. Better have an own properties with debug level set to 
INFO.

2) I cannot guarantee that it will not run into a deadlock, thus it can freeze 
the UI and generate lots of debug output. Again see 1) and kill the program 
after around 5 minutes latest.

But for reasonable (up to moderate difficult) networks it will give results 
nearly immediately.

This is still not the algorithm of Alex, which has pretty amazing running 
times, but a simple brute force algorithm on the current (moderately 
optimized) network graph.

Stefan

Re: [Rails-devel] Experimental version of revenue calculation

[Chris S. <chr...@gm...>]

Since there are more non-programmer end-users running rails, shouldn't the
default for logging be INFO?

--
Chris

Please consider the environment before printing this e-mail.


On Mon, Apr 12, 2010 at 10:50 AM, Stefan Frey (web.de)
<ste...@we...>wrote:

> There is a first working version for revenue calculation in CVS.
> The interface is minimal and added to the graph view:
>
> Thus in the ORWindow select Info => NetworkInfo and the
> public company. Then the graph is displayed and the optimal revenue result
> and
> the vertexes run for each train for the result.
>
> After this one can add additional trains and the optimization restarts.
>
> For available traintypes (currently default (including diesel), +, E and D
> trains) check the addTrainByString method in RevenueAdapter.
>
> BE CAREFUL:
> 1) It generates a lot of debug in the 18xx.log if the logging level is set
> to
> DEBUG (as it is the default). If one tests complicated cases it can fill up
> the hd quite quickly. Better have an own properties with debug level set to
> INFO.
>
> 2) I cannot guarantee that it will not run into a deadlock, thus it can
> freeze
> the UI and generate lots of debug output. Again see 1) and kill the program
> after around 5 minutes latest.
>
> But for reasonable (up to moderate difficult) networks it will give results
> nearly immediately.
>
> This is still not the algorithm of Alex, which has pretty amazing running
> times, but a simple brute force algorithm on the current (moderately
> optimized) network graph.
>
> Stefan
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Experimental version of revenue calculation

[Phil D. <de...@gm...>]

I recall a discussion on this a couple of months back.  I think the
general consensus was that at the moment, debug logging doesn't
significantly impact runtime performance and doesn't cause enough data
to be a disk space issue.  The benefit in terms of making it easy for
users to submit bug reports with logging data was worth leaving it on.

I suspect as and when this change goes live we might want to revisit
that decision

As far as the changes go, sounds exciting, I'll load up my current
PBEM games and run them with this feature on and see what feedback we
can give

Phil

On 12 April 2010 19:09, Chris Shaffer <chr...@gm...> wrote:
> Since there are more non-programmer end-users running rails, shouldn't the
> default for logging be INFO?
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Mon, Apr 12, 2010 at 10:50 AM, Stefan Frey (web.de) <ste...@we...>
> wrote:
>>
>> There is a first working version for revenue calculation in CVS.
>> The interface is minimal and added to the graph view:
>>
>> Thus in the ORWindow select Info => NetworkInfo and the
>> public company. Then the graph is displayed and the optimal revenue result
>> and
>> the vertexes run for each train for the result.
>>
>> After this one can add additional trains and the optimization restarts.
>>
>> For available traintypes (currently default (including diesel), +, E and D
>> trains) check the addTrainByString method in RevenueAdapter.
>>
>> BE CAREFUL:
>> 1) It generates a lot of debug in the 18xx.log if the logging level is set
>> to
>> DEBUG (as it is the default). If one tests complicated cases it can fill
>> up
>> the hd quite quickly. Better have an own properties with debug level set
>> to
>> INFO.
>>
>> 2) I cannot guarantee that it will not run into a deadlock, thus it can
>> freeze
>> the UI and generate lots of debug output. Again see 1) and kill the
>> program
>> after around 5 minutes latest.
>>
>> But for reasonable (up to moderate difficult) networks it will give
>> results
>> nearly immediately.
>>
>> This is still not the algorithm of Alex, which has pretty amazing running
>> times, but a simple brute force algorithm on the current (moderately
>> optimized) network graph.
>>
>> Stefan
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Experimental version of revenue calculation

[Phil D. <de...@gm...>]

Stefan,

A quick test on my currently running 18Kaas game threw up one thing
for the algorithm and a vaguely related issue that certainly needs
consideration for automatic revenue generation.

I generated the network info for NYNH in the attached scenario,
firstly, it ran one of the 2 trains by just counting the revenue for
hex G10 on it's own.  In this case NYNH doesn't really have 3 legal
runs for it's 3 trains so I understand why it did this.  It needs to
be limited to not allow runs of only one station (unless there is a
game out there that allows this that I am unaware of?).

The second issue (and less of an algorithm problem) is that the Ruhr
is listed as an income of 2.  This is simply how I assume we have
chosen to represent the 'doubles cities' power of the Ruhr offboard.
If revenue generation is to work for 18Kaas we will need to represent
this differently.  Of course, that is a whole other discussion on it's
own, as far as I can tell different gaming groups handle this rule
totally differently so there may be some discussion as to what the
official ruling is!

Phil

On 12 April 2010 18:50, Stefan Frey (web.de) <ste...@we...> wrote:
> There is a first working version for revenue calculation in CVS.
> The interface is minimal and added to the graph view:
>
> Thus in the ORWindow select Info => NetworkInfo and the
> public company. Then the graph is displayed and the optimal revenue result and
> the vertexes run for each train for the result.
>
> After this one can add additional trains and the optimization restarts.
>
> For available traintypes (currently default (including diesel), +, E and D
> trains) check the addTrainByString method in RevenueAdapter.
>
> BE CAREFUL:
> 1) It generates a lot of debug in the 18xx.log if the logging level is set to
> DEBUG (as it is the default). If one tests complicated cases it can fill up
> the hd quite quickly. Better have an own properties with debug level set to
> INFO.
>
> 2) I cannot guarantee that it will not run into a deadlock, thus it can freeze
> the UI and generate lots of debug output. Again see 1) and kill the program
> after around 5 minutes latest.
>
> But for reasonable (up to moderate difficult) networks it will give results
> nearly immediately.
>
> This is still not the algorithm of Alex, which has pretty amazing running
> times, but a simple brute force algorithm on the current (moderately
> optimized) network graph.
>
> Stefan
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Experimental version of revenue calculation

[Phil D. <de...@gm...>]

Further to this example...if you generate the B&M network in this
game, it gives you 60 as the routes, it won't count the offboard twice
for two separate trains even though as far as I'm aware that's valid
in this case.

Phil

On 13 April 2010 11:33, Phil Davies <de...@gm...> wrote:
> Stefan,
>
> A quick test on my currently running 18Kaas game threw up one thing
> for the algorithm and a vaguely related issue that certainly needs
> consideration for automatic revenue generation.
>
> I generated the network info for NYNH in the attached scenario,
> firstly, it ran one of the 2 trains by just counting the revenue for
> hex G10 on it's own.  In this case NYNH doesn't really have 3 legal
> runs for it's 3 trains so I understand why it did this.  It needs to
> be limited to not allow runs of only one station (unless there is a
> game out there that allows this that I am unaware of?).
>
> The second issue (and less of an algorithm problem) is that the Ruhr
> is listed as an income of 2.  This is simply how I assume we have
> chosen to represent the 'doubles cities' power of the Ruhr offboard.
> If revenue generation is to work for 18Kaas we will need to represent
> this differently.  Of course, that is a whole other discussion on it's
> own, as far as I can tell different gaming groups handle this rule
> totally differently so there may be some discussion as to what the
> official ruling is!
>
> Phil
>
> On 12 April 2010 18:50, Stefan Frey (web.de) <ste...@we...> wrote:
>> There is a first working version for revenue calculation in CVS.
>> The interface is minimal and added to the graph view:
>>
>> Thus in the ORWindow select Info => NetworkInfo and the
>> public company. Then the graph is displayed and the optimal revenue result and
>> the vertexes run for each train for the result.
>>
>> After this one can add additional trains and the optimization restarts.
>>
>> For available traintypes (currently default (including diesel), +, E and D
>> trains) check the addTrainByString method in RevenueAdapter.
>>
>> BE CAREFUL:
>> 1) It generates a lot of debug in the 18xx.log if the logging level is set to
>> DEBUG (as it is the default). If one tests complicated cases it can fill up
>> the hd quite quickly. Better have an own properties with debug level set to
>> INFO.
>>
>> 2) I cannot guarantee that it will not run into a deadlock, thus it can freeze
>> the UI and generate lots of debug output. Again see 1) and kill the program
>> after around 5 minutes latest.
>>
>> But for reasonable (up to moderate difficult) networks it will give results
>> nearly immediately.
>>
>> This is still not the algorithm of Alex, which has pretty amazing running
>> times, but a simple brute force algorithm on the current (moderately
>> optimized) network graph.
>>
>> Stefan
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>