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 :) Ahhh, I thought you were aiming for conciseness :-) My bad. Trying to pay attention to too many things at once...
How about a ScoreState which builds an index using an arbitrary tuple of IntKeys (or an arbitrary tuple of keys). It would be very trivial to write (using templates in C++, perhaps an alternate python version would be good).
> > > 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 >>>>> 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