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 drussel@gmail.com 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 kerenl@salilab.org 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 kerenl@salilab.org >>>>> 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 >>>>>> IMP-dev@salilab.org >>>>>> https://salilab.org/mailman/listinfo/imp-dev >>>>>> >>>>> _______________________________________________ >>>>> IMP-dev mailing list >>>>> IMP-dev@salilab.org >>>>> https://salilab.org/mailman/listinfo/imp-dev >>>> >>>> _______________________________________________ >>>> IMP-dev mailing list >>>> IMP-dev@salilab.org >>>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >