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
>