It seems entirely useless to me as written as it can only restrict coordinates relative to the origin. I propose getting rid of it and instead providing, as needed, SphericalDistanceRestraint (restraint the distance from a fixed point), CoordinateRestraint (which restricts a coordinate relative to a fixed value) etc. The names could use some work.
My suggestion for SphericalDistanceRestraint (which is what I want) is: SphericalDistanceRestraint(Model*, ParticleIndex (or Particle*), Float x, Float y, Float z, ScoreFunc *f);
Then you can enforce any spherically symmetric restraint on a set of particles (in my case enforcing that they are all in some sphere bounding the system).
Daniel Russel wrote: > It seems entirely useless to me as written as it can only restrict > coordinates relative to the origin.
Hmm, you're absolutely right. I'd assumed that it could actually do something useful, like restrict coordinates to a fixed value. So it's entirely useless to me too.
I guess it was written to use the origin because systems like the NPC are centered at the origin. But that's hardly very general.
> I propose getting rid of it and > instead providing, as needed, SphericalDistanceRestraint (restraint > the distance from a fixed point), CoordinateRestraint (which restricts > a coordinate relative to a fixed value) etc. The names could use some > work. > > My suggestion for SphericalDistanceRestraint (which is what I want) is: > SphericalDistanceRestraint(Model*, ParticleIndex (or Particle*), Float > x, Float y, Float z, ScoreFunc *f);
Sounds fine to me.
Ben
On further thought, I have a slightly different suggestion for spherical restraint.
SphericalRestraint(Model*, ParticleIndex, FloatKeys keys, Floats center, ScoreFunc*);
The advantage of this is that you can use whatever coordinates you want for the restraint and however many you want. So you can also use it to restraint a single coordinate or a pair of coordinates.
I would suggest the constructor for DistanceRestraint be made to be similar.
On Dec 14, 2007, at 9:46 AM, Ben Webb wrote:
> Daniel Russel wrote: >> It seems entirely useless to me as written as it can only restrict >> coordinates relative to the origin. > > Hmm, you're absolutely right. I'd assumed that it could actually do > something useful, like restrict coordinates to a fixed value. So it's > entirely useless to me too. > > I guess it was written to use the origin because systems like the NPC > are centered at the origin. But that's hardly very general. > >> I propose getting rid of it and >> instead providing, as needed, SphericalDistanceRestraint (restraint >> the distance from a fixed point), CoordinateRestraint (which >> restricts >> a coordinate relative to a fixed value) etc. The names could use some >> work. >> >> My suggestion for SphericalDistanceRestraint (which is what I want) >> is: >> SphericalDistanceRestraint(Model*, ParticleIndex (or Particle*), >> Float >> x, Float y, Float z, ScoreFunc *f); > > Sounds fine to me. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Daniel Russel wrote: > On further thought, I have a slightly different suggestion for > spherical restraint. > > SphericalRestraint(Model*, ParticleIndex, FloatKeys keys, Floats > center, ScoreFunc*); > > The advantage of this is that you can use whatever coordinates you > want for the restraint and however many you want. So you can also use > it to restraint a single coordinate or a pair of coordinates.
The downside, of course, is then you can't make the x/y/z static. But it sounds reasonable to me.
> I would suggest the constructor for DistanceRestraint be made to be > similar.
I'd like to keep the existing constructor, since distance restraints are probably almost always going to be on x/y/z. But by all means add a new constructor too.
Ben
On Dec 14, 2007, at 1:06 PM, Ben Webb wrote: > The downside, of course, is then you can't make the x/y/z static. > But it > sounds reasonable to me. True. However, the real cost with the Keys is construction, not copying, and it does eliminate the multiple constructions.
> > >> I would suggest the constructor for DistanceRestraint be made to be >> similar. > > I'd like to keep the existing constructor, since distance restraints > are > probably almost always going to be on x/y/z.
True enough. I just hardcode x,y,z for now.
participants (2)
-
Ben Webb -
Daniel Russel