I think we should have a new class of object, which I am, for the
time being calling a ParticleRefiner to handle hierarchical
collision detection and generation of particles on the fly. I am
currently using it to generate particles to cover the edges of my
unstructured chains in order to better preserve excluded volume.
The interface looks more or less like:
ParticleRefiner {
// return a bunch of particles which refines p
Particles refine(Particle p)
// clean up the particles which refined p if needed
cleanup(Particle p, Particles);
};
And the methods must be called as a pair with the result of the
first method passed as the second argument to the second method.
Sounds reasonable to me. But what if the user passes a different
list to cleanup?
It could be hard to check, true.
What sort of bad things would happen? Why couldn't the Refiner just
keep its own list of particles?
I need to be able to refine two particles (for example when doing
collision detection) using the same refiner (or pass two identical
copies of the refiner). As a result, the refiner would have to
maintain a map internally, which seems a bit heavy since the external
user has the lists already.
Also, it seems like there's some overlap between this and
CoverBondsScoreState.
Yeah, the logic from that would move into such a class.