True, but is our only current hook for keeping things up to date. One alternative would be to add hooks to monitor attribute changes, but that would be tricky to make not expensive. You don't have to add states to a model though, so you could update it manually if you want.
On Dec 9, 2008, at 11:08 AM, "Dina Schneidman" duhovka@gmail.com wrote:
> 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 >> > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev