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