Title M&S refactoring part 2: separate out LabelReduction from Labels
Priority wish Status resolved
Superseder Nosy List malte, silvan
Assigned To silvan Keywords
Optional summary

Created on 2015-12-01.16:51:28 by silvan, last changed by silvan.

msg4881 (view) Author: silvan Date: 2015-12-07.10:15:46
Version 3 includes polishing and factoring out commonly used typedefs in a new
file types.h/cc

No changes in performance:

To proceed with the sprint, I'll merge this issue now.
msg4855 (view) Author: silvan Date: 2015-12-03.17:38:39
In version 2, TransitionSystems and Labels as constructed by the FTSFactory and
used in FactoredTransitionSystem are unique pointers rather than raw ones. More
importantly, FactoredTransitionSystems became a unique pointer managed by the
heuristic; all users of it get access to a reference they may modify.


Besides some changes due to just hitting the time limit or not, there are no
visible changes in performance.
msg4854 (view) Author: malte Date: 2015-12-03.17:38:20
Sounds good to me. (I looked at the results.)
msg4853 (view) Author: silvan Date: 2015-12-03.17:28:26
In version 1, I extracted all methods related to label reduction into their own
class. The now very thin Labels class object is managed by
FactoredTransitionSystem. As a consequence, label reduction cannot directly
modify the set of labels anymore, but needs to do this via
FactoredTransitionSystem. This could potentially incur an overhead for the
already expensive computation of label reduction.


There is indeed a slight increase of score_total_time_average and
score_memory_average across several configurations. I still think this is okay,
given that the code got cleaner this way (label reduction is now an optional
option, detached from the Labels object, which is of course always required.)
msg4849 (view) Author: silvan Date: 2015-12-01.16:51:28
This is part of meta issue567.

I want to pull out the label reduction functionality from the Labels class,
because the Labels class is used at many places, whereas the label reduction
only happens in the merge and shrink main loop. The Labels class could be owned
by FactoredTransitionSystem, and LabelReduction, similarly to merge and shrink
strategies, will be managed by the merge-and-shrink heuristic itself.

This issue probably will perform further small refactoring of the
merge-and-shrink main loop and the FactoredTransitionSystem class.
Date User Action Args
2015-12-07 10:15:50silvansetstatus: in-progress -> resolved
2015-12-07 10:15:46silvansetmessages: + msg4881
2015-12-03 17:38:39silvansetmessages: + msg4855
2015-12-03 17:38:20maltesetmessages: + msg4854
2015-12-03 17:28:26silvansetmessages: + msg4853
2015-12-01 16:51:28silvancreate