IMP-dev

imp-dev@salilab.org

869 discussions

Last week in IMP
by Daniel Russel 26 Jun '09

26 Jun '09

Nothing too much changed: * box distrubutions (IMP::algebra::random_vector_on_box(), IMP::algebra::random_vector_in_box()) take bounding boxes * IMP::em::DensityMap are now IMP::Object objects. Some current allocations on the stack may need to be changed. * IMP::em::DensityMap::Read() is now deprecated (as is Write). Use the more conventional IMP::em::read_map() and IMP::em::write_map() instead. Remember, any time an object accepts and stores a pointer to another object, the passed object must be reference counted. Otherwise it is very difficult for users to get memory management correct. To make an object reference counted inherit from RefCounted or Object and used IMP::Pointer instead of a raw pointer to store.

3 2

ScoreState vs Constraints
by Daniel Russel 16 Jun '09

16 Jun '09

The name ScoreState seems to confuse a few people. As Hao pointed out, they are actually constraints. Any reasons not to rename them to that? It would be a relatively easy shell script (and user code could be updated via sed).

2 1

Decorators vs particles
by Daniel Russel 16 Jun '09

16 Jun '09

The issue of functions taking Decorator objects, or Decorators objects as arguments vs Particle* and Particles keeps coming up. Mostly we currently are going for Decorator objects and Particles the moment which is reasonably practical, but odd. Taking decorators makes the docs better (since it is clear what is expected from the particles), but then you have to convert things back and forth everywhere. One solution for this on the C++ side would be to: - write all methods to take Decorator objects and Decorators. This makes the docs nice and doesn't require duplicating methods - allow implicit conversions from Particle* to Decorator objects (I currently disallowed it) - allow implicit conversions from Particles to Decorators (by making Decorators be something other than std::vector, which is easy enough) Ben, can such be made to work on the python side too via typemaps? I had looked at doing implicit conversions at some point and couldn't quite figure out how to make it work.

2 2

This week in IMP
by Daniel Russel 12 Jun '09

12 Jun '09

- new methods IMP::atom::add_radii() and IMP::atom::add_bonds(); - Hierarchys to IMP::atom::Hierarchies - IMP::Particles has been changed to a new type. It no longer plays quite so well with python lists (you can't create a part one from an arbitrary python list). - The contains for multiple decorators have been revised to make them more useful. See IMP::Decorators. You can now implicitly convert, for example, a IMP::core::XYZs to an IMP::Particles (as well as use IMP::Decorators::get_particles()). All methods that take a collection of particles with a certain type now instead take a IMP::Decorators. - A method that has expectations about the particles it takes should take decorators rather than particles. That is, anything which expects IMP::core::XYZ particles, should take an IMP::core::XYZs instead of IMP::Particles. - IMP_LIST() now takes an extra argument (the name of the plural container) - In C++ IMP::Decorator objects are implicitly convertible to IMP::Particle* objects. Unfortunately, making this work in Python is problematic. - More methods take and return decorators rather than IMP::Particles. This means it is clearer what their expectations are and what they produce.

1 0

Failure rate of restraints
by Daniel Russel 08 Jun '09

08 Jun '09

With Keren, we ran into problem caused the fact that em restraints go to 1 as they are increasingly violated while hard sphere restraints go to larger numbers (and are dependent on the number of particles). The result was that the em restraint would get more or less ignored by the optimizer unless a large scaling factor was added to EM. This experience raises an important question: Do we want a convention about how restraint scores behave as they are increasingly violated? A convention could be something like: - all satisfiable restraints (ones whose optimal is at 0) should have scores that go as x^2 (or just as x) per atom where x is the displacement is angstroms from a satisfying conformation. - a restraint score can stop increasing at a value where there is no longer any signal. Obviously, one could only very roughly approximate this in practice, but a rough approximation might be good enough to get many of the benifits Advantages: - You have a natural starting point for weight values between the various restraints. Variations from this are directly upweighting or downweighting data relative to them having equal importance. - The relative importance of restraints does not depend on how far from optimal you are - The relative importance of restraints does not depend on how many particles they are restraining - The importance of various terms won't depend on the scale of the representation Feasibility: - core restraints such as Diameter and stuff would require using a per-particle scaling factor (to incorporate the number of atoms). Excluded volume is approximately correct too given such a scaling (at least if the model isn't too messed up) - EM would require adding a term to penalize things for escaping far from the map as well as some experiments on how things break down under random displacements of various amounts (and rescaling of cross correlation accordingly) and scaling by the number of particles. Such could easily be added as a wrapper around a CC based restraint. And understanding of those issues seems important anyway. - others?

4 14

has anyone written a heavy atom selector in IMP.atom ?
by Keren Lasker 08 Jun '09

08 Jun '09

2 1

mean orientation
by Keren Lasker 06 Jun '09

06 Jun '09

hi, did anyone figure out how to find the mean orientation from a set of rotations ? It is not a simple mean operator on quaternions as q and - q represent the same orientation. Keren.

2 3

"smart" orientation grid search
by Keren Lasker 02 Jun '09

02 Jun '09

hi all, Has anyone implemented a function that generates a set of grid search orientations ? something like: IMP::algebra::Rotation3D rotation_grid_search(IMP::Float distance); We have sphere based and cylinder based rotation sampling, but it seems that there are better ways (quaternions based) that maintain a fixed "distance" between all pairs of orientations. thanks, Keren.

3 7

compiling imp for 32BIT
by Dina Schneidman 28 May '09

28 May '09

Hi, I need to compile IMP for 32BIT computer (mine is 64BIT) How can I do it? thanks!

2 3

spline interpolation
by Javier Ángel Velázquez Muriel 26 May '09

26 May '09

Hi, I've noticed an OpenCubicSpline class in the core module. I couldn't find an example in the code using grep. Could anybody answer this questions? 1) I understand that the values have to be evenly-spaced. Then, why asking for minrange and spacing ? Why not just use: minrange = values[0]; spacing = values[1]-values[0]; ? 2) What is the minimum number of values required ? 4 ? 3) Do they need to be sorted ? 4) If I want to compute values out of range, should I use ClosedCubicSpline ? 5) Could the author update the help a little bit? Thanks !

2 2

← Newer
1
...
41
42
43
44
45
46
47
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev