Skip to content

SolverManager posponing "floating" state blocks

Sometimes, in our wolf tree there can be "floating" state blocks (frames or landmarks or whatever) and these state blocks shouldn't be added to the solver to avoid ill-defined problem .This doesn't avoid all ill-defined situations, but still I think it is useful to avoid this situation.

I have an implementation in which these state blocks are treated like "truncated" notifications (see #332 (closed)). The floating state blocks will be removed from the solver and an ADD notification is added to the problem's notification list.

This makes fail some tests. Basically, checking if after adding a state block it is in the solver (but it's not because it is floating). So I only see three options:

  1. Forget about this (I wouldn't recommend it)
  2. Change the tests.
  3. Change the SolverManager implementation to fullfill the tests. Put this stateblocks in a container SolverManager::floating_state_blocks (for instance). Also modify SolverManager::isStateBlockRegistered returning true if this state block is stored apart as floating state blocks.

Opinions?