On Tue, Feb 17, 2009 at 5:44 PM, Daniel Russel <> wrote:
>>> 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).
fine. in the past everybody could live with such a user-defined
solution in modeller.
a more advanced automated function would of course always be appreciated ;)
frido
> _______________________________________________
> IMP-dev mailing list
>
> https://salilab.org/mailman/listinfo/imp-dev
>
>