[rules-dev] Score standardization in drools-solver: going beyond a double

[Geoffrey De Smet]

Hi guys,

I 'd like to redesign the current score subsystem in drools-solver,
but I 'd like your thoughts on it.
Basically I feed the subsystem a Solution instance on which the DRL 
rules calculate a score (currently a double).

Here are my thoughts, feed-back very welcome:


Score function standardization
==============================

- Currently a score is a double and that just won't do
- Different types of scores should be implementable:
-- just a (hard) constraint total, as an int
-- just a (hard) constraint total, as a double
-- a hard and a soft constraint total, as 2 ints
-- a total for each constraint, as seperate ints
-- custom implementations
=> So there should be a Score interface
=> Build-in implementation of HardAndSoftScore and IntScore?

- Any 2 scores of the same problem should be comperable for recognizing 
the best solution
=> The score interface must implement Comperable and have the method 
compareTo(Score)

- A score shouldn't change
-- So it can be compared to in later steps
-- You can't do that with the current ScoreCalculator instance as it 
changes all the time.
-- So they can be collected for statistical information
- A score should be thread-safe if possible
=> A Score implementation should be immutable

- A score should be made by the drl, once for every fireAllRules = 
calculateScore
-- What if I start adding move generation and move implementation into 
the drl later? That lifecycle match won't fit no more? Should I look 
into agenda's or flow?
- Should a score be put into a global variable directly or still into a 
global ScoreCalculator (=ScoreHolder?) instance? What's the point of the 
latter?


Extra
=====

- Any 2 scores of the same problem can also be compared on a different 
than normal scale to pick the next step:
-- For recalling the best solution, a hard constraint outweighs any soft 
constraint.
-- For deciding the next step, a hard constraint can be weighted into 
the soft constraints, if hard constraints haven't been broken much in x 
steps.
-- That weighting into can differ from step to step, so it should be 
supplied by the caller
--- Should that weighting be just an int, or something more complex? 
Let's call it an Equalizer for now.
=> The Score interface must have a method compareTo(Score, Equalizer)


-- 
With kind regards,
Geoffrey De Smet