but you don't always want to update you indexing before/after scoring
On Tue, Dec 9, 2008 at 11:06 AM, Daniel Russel <> wrote:
> Score states don't have anything to do with scoring either :-) they are just
> updated before scoring since that is when things can change during
> optimization. They used to just be called States which is perhaps clearer.
>
>
>
> On Dec 9, 2008, at 10:56 AM, "Dina Schneidman" <> wrote:
>
>> maybe it's a simple solution in order to have it in a model, but
>> conceptually this indexing has nothing to do with scoring
>>
>> On Tue, Dec 9, 2008 at 10:42 AM, Daniel Russel <> wrote:
>>>
>>> From what I understand, what you want is a way of specifying what indexes
>>> we
>>> want build (not a way of specifying queries). We could easily provide
>>> ScoreStates for indexes based on:
>>> - set of discrete valued attributes
>>> - D-dimensional interval queries on float values
>>>
>>>
>>> On Dec 9, 2008, at 9:55 AM, Keren Lasker wrote:
>>>
>>>> Daniel - we all know how to run for loops ;)
>>>> I just thought it make sense to have something more efficient :)
>>>>
>>>> On Tue, 9 Dec 2008, Daniel Russel wrote:
>>>>
>>>>>
>>>>> On Dec 9, 2008, at 9:29 AM, Keren Lasker wrote:
>>>>>
>>>>>> For the 26S project we currently do:
>>>>>> get particle by name
>>>>>
>>>>> How could we beat something like:
>>>>> [x for x in myparticles if x.has_attribute(name) and x.get_value(name)
>>>>> ==
>>>>> "myname"]
>>>>> with an SQL query?
>>>>>>
>>>>>> get a set of particles within a residue number range
>>>>>
>>>>> again, some variant on:
>>>>> [x for x in molecular_hierarchy_get_by_type(root,
>>>>> MolecularHierarchyDecorator.RESIDUE) if
>>>>> ResidueDecorator(x).get_index() > lb and
>>>>> ResidueDecorator(x).get_index()
>>>>> <ub]
>>>>>
>>>>> or C++, something like
>>>>> BOOST_FOREACH(Particle *p, molecular_hierarchy_get_by_type(root,
>>>>> MolecularHierarchyDecorator.RESIDUE)) {
>>>>> if (ResidueDecorator(p).get_index() > lb and
>>>>> ResidueDecorator(p).get_index() <ub) {
>>>>> // do something
>>>>> }
>>>>> }
>>>>>>
>>>>>> the solution of a function that gets (key,value,container) seems like
>>>>>> a
>>>>>> good solution.
>>>>>> However - it can be more complicated :
>>>>>> 1. it can interact with the hierarchy - give me the residues range
>>>>>> within this protein for example - so we should probably also allow for
>>>>>> a
>>>>>> hierarchy handle in the interface.
>>>>>> 2. we might want to ask residue range + some other property such as
>>>>>> have
>>>>>> structural coverage or do not. Therefore I think that a sql type
>>>>>> string can
>>>>>> be more general than a list of attributes - because you do not know
>>>>>> how they
>>>>>> are related.
>>>>>
>>>>> But the added complication is why I would suggest sticking with C++ or
>>>>> python. Lambda functions or list comprehensions support very general
>>>>> logic
>>>>> (more so than SQL) and allow you to leverage existing code. SQL would
>>>>> make
>>>>> it really hard to use any of the existing functionality and require
>>>>> lots of
>>>>> things be exposed in another language. For example, try to find all
>>>>> particles close to a point in SQL? It is kind of ugly.
>>>>>
>>>>>> On Tue, 9 Dec 2008, Daniel Russel wrote:
>>>>>>>
>>>>>>> In general, I think having queries on the whole collection of
>>>>>>> particles
>>>>>>> in the model is not a good idea (since other people's code,
>>>>>>> restraints or
>>>>>>> states can add particles to the model and you can never be sure what
>>>>>>> those
>>>>>>> look like).
>>>>>>> There is already functionality to search a Hierarchy (although it is
>>>>>>> more aimed at C++-- we could use a python interface which takes takes
>>>>>>> a
>>>>>>> python lambda function to make it more convenient to use in python).
>>>>>>> And
>>>>>>> python has all sorts of features for searching a list (and C++ has a
>>>>>>> few).
>>>>>>> It is not clear to me that we could provide an interface that is
>>>>>>> general and much more concise.
>>>>>>> As a slight simplification for python users, we could provide a
>>>>>>> function which takes a list of key, value pairs (with keys of
>>>>>>> arbitrary
>>>>>>> type) and a container. It is a bit messier to provide this interface
>>>>>>> in C++
>>>>>>> as we would have to have a separate list per type.
>>>>>>> Another thing to simplify such search would be a
>>>>>>> "DefaultValuesDecorator" which wraps a particle and pretend it has
>>>>>>> all
>>>>>>> attributes, just providing default values for missing ones. This
>>>>>>> would
>>>>>>> obviate the need to check for an attribute before matching against
>>>>>>> it.
>>>>>>> What sort of queries do you all do?
>>>>>>> On Dec 9, 2008, at 8:43 AM, Dina Schneidman wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I need this too (surprisingly). Usually I do it with mapping between
>>>>>>>> the particle and the attribute.
>>>>>>>> It is simple. however it is unclear where should we put such a
>>>>>>>> mapping. Putting it in a model
>>>>>>>> could be the best, however not everyone needs it. So it means
>>>>>>>> somewhere else or extending the Model to ProteinModel?
>>>>>>>> Dina
>>>>>>>> P.S. skype me, we can talk about it
>>>>>>>> On Tue, Dec 9, 2008 at 7:03 AM, Keren Lasker <>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> hi all,
>>>>>>>>> Frido and I find ourselves many times need to query particles based
>>>>>>>>> on
>>>>>>>>> attribute values.
>>>>>>>>> Few such examples: a protein with a specific name, particles with a
>>>>>>>>> specific
>>>>>>>>> residue range.
>>>>>>>>> I think that it would be very useful to have something similar to
>>>>>>>>> SQL
>>>>>>>>> queries on the particles DB.
>>>>>>>>> Bret might had something similar implemented - but it is probably
>>>>>>>>> obsolete.
>>>>>>>>> IMP.Atom will probably need such functionality as well.
>>>>>>>>> has anyone took a look at that before ?
>>>>>>>>> thank you,
>>>>>>>>> Keren.
>>>>>>>>> _______________________________________________
>>>>>>>>> IMP-dev mailing list
>>>>>>>>>
>>>>>>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> IMP-dev mailing list
>>>>>>>>
>>>>>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> IMP-dev mailing list
>>>>>>>
>>>>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> IMP-dev mailing list
>>>>>>
>>>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>>
>>>>> _______________________________________________
>>>>> IMP-dev mailing list
>>>>>
>>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>
>>>> _______________________________________________
>>>> IMP-dev mailing list
>>>>
>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>
>>> _______________________________________________
>>> IMP-dev mailing list
>>>
>>> https://salilab.org/mailman/listinfo/imp-dev
>>>
>> _______________________________________________
>> IMP-dev mailing list
>>
>> https://salilab.org/mailman/listinfo/imp-dev
>
> _______________________________________________
> IMP-dev mailing list
>
> https://salilab.org/mailman/listinfo/imp-dev
>