proposal to simplify implementation of collections of decorators and particles
Currently, lists of decorators and particles in IMP are implemented using some rather complicated an brittle custom containers and a reasonable runtime cost for iterating through Particles and Decorators. I would like to remove this code and replace the implementations by plain std::vectors (and std::vector<Pointer> when reference counting is needed). This would result in no difference to the python API, which does not use these containers at all. On the C++ side, there would be some significant changes, in particular
- atom::Hierarchies would no longer inherit from core::Hierarchies and core::XYZRs would no longer inherit from core::XYZs, so certain code which assumes an implicit conversion from one to the other would break. Fixing the code would require addding IMP::get_as calls and a copy, or, ultimately better, just storing Particles and ParticlesTemp objects and constructing the decorators on demand
- Particles no longer would inhertit from ParticlesTemp, so similar implicit conversions from one to the other would need get_as calls (which would result in a copy). From perusing the code, most of these conversions are occur in places when a Particles could be replaced by a ParticlesTemp with no loss of functionality (and a marginal speedup).
These changes are likely to require many straight forward changes to existing code. So I'm a bit ambivalent.
Daniel, did you make these changes? Did you correct the svn code?
On 7/25/11 11:54 AM, Daniel Russel wrote: > Currently, lists of decorators and particles in IMP are implemented using some rather complicated an brittle custom containers and a reasonable runtime cost for iterating through Particles and Decorators. I would like to remove this code and replace the implementations by plain std::vectors (and std::vector<Pointer> when reference counting is needed). This would result in no difference to the python API, which does not use these containers at all. On the C++ side, there would be some significant changes, in particular > > - atom::Hierarchies would no longer inherit from core::Hierarchies and core::XYZRs would no longer inherit from core::XYZs, so certain code which assumes an implicit conversion from one to the other would break. Fixing the code would require addding IMP::get_as calls and a copy, or, ultimately better, just storing Particles and ParticlesTemp objects and constructing the decorators on demand > > - Particles no longer would inhertit from ParticlesTemp, so similar implicit conversions from one to the other would need get_as calls (which would result in a copy). From perusing the code, most of these conversions are occur in places when a Particles could be replaced by a ParticlesTemp with no loss of functionality (and a marginal speedup). > > These changes are likely to require many straight forward changes to existing code. So I'm a bit ambivalent. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
I haven't made any of those changes yet.
On Aug 5, 2011, at 7:02 PM, Javier Velazquez wrote:
> Daniel, did you make these changes? Did you correct the svn code? > > On 7/25/11 11:54 AM, Daniel Russel wrote: >> Currently, lists of decorators and particles in IMP are implemented using some rather complicated an brittle custom containers and a reasonable runtime cost for iterating through Particles and Decorators. I would like to remove this code and replace the implementations by plain std::vectors (and std::vector<Pointer> when reference counting is needed). This would result in no difference to the python API, which does not use these containers at all. On the C++ side, there would be some significant changes, in particular >> >> - atom::Hierarchies would no longer inherit from core::Hierarchies and core::XYZRs would no longer inherit from core::XYZs, so certain code which assumes an implicit conversion from one to the other would break. Fixing the code would require addding IMP::get_as calls and a copy, or, ultimately better, just storing Particles and ParticlesTemp objects and constructing the decorators on demand >> >> - Particles no longer would inhertit from ParticlesTemp, so similar implicit conversions from one to the other would need get_as calls (which would result in a copy). From perusing the code, most of these conversions are occur in places when a Particles could be replaced by a ParticlesTemp with no loss of functionality (and a marginal speedup). >> >> These changes are likely to require many straight forward changes to existing code. So I'm a bit ambivalent. >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > -- > Javier Velazquez > Postdoc at Salilab, UCSF > 1700 4th st. Byers Hall, office 503. > 94158 San Francsico > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
participants (2)
-
Daniel Russel -
Javier Velazquez