Benchmark GB_Con.InCosetSimple versus GB_Con.InCoset (etc)

[wilfwilson]

(This is perhaps more of a GraphBacktracking issue, but since we're working on Vole at the moment I think it's better to put it here.)

Currently:

• VoleCon.InCoset translates to:
  • GB_Con.InCosetSimple in canonicalconstraints.g, rather than GB_Con.InCoset in simpleconstraints.g.
• On the other hand, VoleCon.InGroup translates to:
  • GB_Con.InGroup in simpleconstraints.g rather than GB_Con.InGroupSimple in canonicalconstraints.g.

About a month ago I switched VoleCon.InGroup to GB_Con.InGroup in the possibly-mistaken belief that GB_Con.InGroupSimple was slower (i.e. produced larger searches) than necessary, in order to be compatible with canonical images, but that since VoleCon.InGroup is not a valid constraint for a canonical image search, we didn't need to take this compatibility into account. So we could use the 'non-simple' one instead.

Note that the group refiners are just instances of the coset refiners with the representative being the identity.

Basically: I want it to be clear which refiners we should be using in Vole.

Things to do:

• Name things more clearly.
• Clearly denote (with comments) what the purpose/idea of each refiner is.
• Benchmark the search size and time taken.
  • Chris thinks that the cosets refiners should produce (on average) the same sized searches, but that the 'simple' one might be faster overall, especially if you're doing repeated searches with the same group(s).

[wilfwilson]

With the new constraints setup, in Vole, the conversion of Constraint.InGroup/Constraint.InCoset is done by GraphBacktracking, which always uses the the refiner GB_Con.InCoset and never GB_Con.InCosetSimple. I fear that this may have made things slower.