Re: [Rails-devel] Implementation details for revenue calculation

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

I'm with Stefan on this one. We have rather strictly defined problem. Our  
domain is well-defined - connectivity graph (with weighted vertices), set  
of trains (here "train" is just a convenient term that can stand for  
anything because it's only used to pass to route valuation function) and  
route valuation function. Co-domain is a set of vertex sequences. The goal  
is to find a transformation that has maximal total value of vertex  
sequences. This operator is our optimal route searching algorithm. It does  
not depend on rules from any specific game - in theory it could be applied  
to some completely different domain, not even related to train or games.  
There is nothing to subclass (or specialize) in it really. A common  
analogy would be something like standard sorting algorithm - either you  
use it as given or you use completely different sorting algorithm, perhaps  
specialized for your particular sequence. Getting back to the train games,  
revenue in Chicago Express would be findable by this approach, but much  
simpler and more efficient algorithm can be implemented for that game.

This leaves 2 pieces of code: one to transform game data into the  
connectivity graph and another - to implement route valuation function. I  
think in both cases rather generic algorithm can take care of most cases  
(for route valuation, the method (or some variation of it) proposed by  
Stefan in another message will work). This will simplify implementing  
various games. However, as those are just inputs into a main solver,  
different implementations can be provided for the games that don't fit  
into the common pattern. This is essentially the same principle as  
sub-classing. Whether it's implemented as sub-classing or as function  
arguments is a minor detail.

Alex.

On Tue, 27 Apr 2010 17:22:19 -0600, Stefan Frey (web.de)  
<ste...@we...> wrote:

> Brett:
> the example you gave below is an example of a class that I have created,  
> thus
> I am aware of that ;-)
>
> And I think that is not the path to choose for the cases we are  
> discussing
> here.
>
> Subclassing implies that the interface to the subclasses includes all
> implementation details of the parent class: This is a blessing and a  
> curse at
> the same time. It makes the implementation of the details easy, as you  
> can
> change everything you like. The price to pay is that you cannot change  
> the
> parent class anymore without checking that you do not break any of your  
> (or
> even worse someone else's) subclasses.
>
> For the revenue calculator I prefer an approach similar to the strategy
> pattern to define the different special rules to the subclassing  
> approach.
>
> Another reason is that the revenue calculator itself implements some
> optimizations, that require advanced knowledge of the problem to solve.  
> Thus
> it would be easy to write special rules subclasses, that would not work
> anymore with some of the optimizations. By narrowing the possible  
> extensions
> I keep control of that.
>
> I admit that some of the arguments are also valid for other classes in  
> Rails.
> Many important classes (as for example OR) are available for subclassing.
> This imposes a high risk of breaking something if you change any of those
> classes. But I also admit that those risks are most likely  
> (over)compensated
> by  the easeness to allow the implementation of specific game rules.
>
> Stefan
>
> On Wednesday 28 April 2010 00:52:30 brett lentz wrote:
>>
>> This is probably where you may want to look to the rules-enforcement
>> for guidance.
>>
>> We've tried to create a class hierarchy that allows us to describe
>> objects in the general sense, and then specify game-specific objects
>> that implement specific exceptions when necessary.
>>
>> Example: OperatingRound vs. OperatingRound_1889.
>>
>> In the same way, you'll likely want a generic calculator that covers
>> "normal" cases, and then for games that use special rules, subclass
>> out the specific exceptions they create and override the parent class
>> methods with more specific implementations.
>>
>> ---Brett.
>>
>> ---------------------------------------------------------------------------
>> --- _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/