but you don't always want to update you indexing before/after scoring
On Tue, Dec 9, 2008 at 11:06 AM, Daniel Russel drussel@gmail.com wrote: > Score states don't have anything to do with scoring either :-) they are just > updated before scoring since that is when things can change during > optimization. They used to just be called States which is perhaps clearer. > > > > On Dec 9, 2008, at 10:56 AM, "Dina Schneidman" duhovka@gmail.com wrote: > >> 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 >>> >> _______________________________________________ >> 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 >