Move in more preprocessing composites

[hhtong]

• rename fix_variables() to roof_duality() and move to new lower_bounds module
• move in more preprocessing composites (ClipComposite, ConnectedComponentsComposite, FixVariablesComposite, ScaleComposite, and SpinReversalTransformComposite)
• remove RoofDualityComposite and move functionality into an option in FixVariablesComposite

[hhtong]

Have spoken with @amahmudwave , who will expose the lower bound after this PR gets merged

[randomir]

This API is too specialized, and we'll have to break it the very next time we add an algorithm.

I propose:

Suggested change

	def __init__(self, child_sampler, *, fixed_variables=None, algorithm=None, strict=True):
	def __init__(self, child_sampler: dimod.Sampler, *, algorithm: str = 'explicit', params: Optional[dict] = None):
	self._algorithm = algorithm
	self._params = params
	self._algorithms = <map of callables>

and then for sampling:

def sample(self, bqm, **parameters):
    algo = self._algorithm[self._algorithm](**self._params)
    return algo(bqm, **parameters)

So params can be specified per algorithm. For algorithm == 'explicit', param could be assignments, and for algorithm == 'roof_duality', we'd use strict.

The above is just a sketch, and we might want to use Enum instead of string for algorithm, and name variables differently.

[randomir]

Or, we can specify algorithm in __init__ and then algorithm parameters as parameters of the sample method.

In that case, we would have to (dynamically) set composite's parameters on init, depending on the chosen algorithm.

Makes sense, but I'm not sure how well it fits in dimod's composite framework. @arcondello, thoughts?

[arcondello]

That makes sense to me. The main assumption is that we treat it as immutable once it's instantiated. Though of course there are exceptions.

[hhtong]

Updated in latest commit to specifying algorithm in __init__ and the rest of the parameters in **parameters of .sample(). I'm not entirely certain that the way I'm handling the parameters property is correct though. I also kept algorithm as a string for now (I imagine this will become a callable later on, once we've finalized how roof_duality() works)

[amahmudwave]

I can return a lower bound but it will be subject to numerical errors, since floats are getting converted to llint and then back to float again. So it will be off by a small amount. Are there tests to validate the numbers that I will return with a tolerance for such discrepancy ?

Oh I realize, the question may not be relevant to this PR :), nevermind.

[randomir]

LGTM!