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