I mean having an indexing that lets you find the residue you want in
O(1) rather than looping.
On Tue, Dec 9, 2008 at 9:54 AM, Daniel Russel <> wrote:
>
> On Dec 9, 2008, at 9:53 AM, Dina Schneidman wrote:
>
>> I think IndexModel is the best solution, but in C++. having python and
>> c++ is more than enough, we don't want to support something else. I
>> suggested extending the Model because of the update reason, in this
>> case you can update the indexing when you add/remove particles.
>
> I don't understand what you mean.
>
>>
>>
>> On Tue, Dec 9, 2008 at 9:29 AM, Keren Lasker <> wrote:
>>>
>>> For the 26S project we currently do:
>>> get particle by name
>>> get a set of particles within a residue number range
>>>
>>>
>>> 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.
>>>
>>>
>>> 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
>