>> It came up in the context of rigid bodies that certain optimizers >> (namely CG) like to have all their parameters vary over a similar >> scale. As a result, it can be important to rescale non-xyz >> attributes. One way of doing this would be to add a method to >> Model: FloatPair get_range(FloatKey) which returns the current >> range of values for a particular FloatKey. Then CG could use that >> to rescale all its values internally. > something like that would be useful indeed. the typical changes of > the values would be of importance for optimizers - the absolute > values are not really important. thus, this function would somehow > need to accumulate knowledge on the magnitude of changes for the > variables throughout optimization. I was thinking to use the relative magnitudes as a proxy for the relative changes, but that doesn't always make sense. However, for the rigid body case they probably do a good enough job: that is, for computing a structure from a random conformation x,y,z and the angles will go through their whole range, and if you are just refining the structure, and have reasonable sized rigid bodies, they will both go through a small, roughly comparable, fraction of their range. This does not hold if we are using internal coordinates for a protein or similar non-xyz variables.
Tracking changes is problematic as they are highly variable when you use something like CG and past behavior does not predict the future well (since things settle down). I was trying to use the changes over the last few steps to predict how much slack to add in the non-bonded list, and that was just a mess.
So a refined suggestion: Model would have a parameter called scale per optimizeable attribute. This scale is by default the width of the range of values exhibited for that attribute, but can be set to anything by the user. Optimizers can use this scale as a hint to improve performance (that is, it is non-binding).