[gmx-developers] Some thoughts about new trajectory analisys api
roland at utk.edu
Tue Feb 5 20:59:00 CET 2013
On Tue, Feb 5, 2013 at 2:33 PM, Teemu Murtola <teemu.murtola at iki.fi> wrote:
>>> Actually that suggestion is very non-std like. It combines access to the
>>> complete range of coordinates ,with the algorithm (copy), and thus is
>>> less flexible because these two things can't be combined differently.
>>> So it might be better to provide: "iterator xBegin()" and "iterator
>>> xEnd()". That would allow to copy using:
> I think the best way is to provide a method like ConstArrayRef<rvec>
> positionArray() const, which automatically gives those iterators as well.
> Haven't tried this, but this should compile.
That is indeed better. And much simpler. I didn't realize that the
positions are stored in gmx_ana_pos_t::x and that it is contiguous. I had
assumed that the storage is a structs of positions (x,v,f,x,v,f, ..... )
and thus thought it would be more difficult.
> But using std::copy() on a container of rvecs doesn't work, because rvec
> is not copyable or assignable. This part still needs work, but is a more
> general problem than just in the analysis framework.
You're right. One of the reasons why we need to decide ASAP on a rvec
> But I'm not sure we discussed how much we want to make use of iterators.
>>> Our modified version changes that mpp uses iterators and we think it got
>>> better/more flexible by doing that. I think Teemu tried to avoid them.
> You are probably referring to http://redmine.gromacs.org/issues/856.
Actually I had forgotten about that. I was commenting on the fact that you
haven't implemented many custom iterators.
> Overall, iterators are nice (and several classes in the code provide
> iterator access or take iterators as parameters), but for that particular
> case would have been tricky to implement (and would still not have strictly
> fulfilled the strict requirements for an iterator). Also, I'm using
> iterators extensively for loopring over containers.
>> Iterators are not mentioned at all on http://www.gromacs.org/index.**
> It does mention that "do use STL". ;) And STL uses iterators
> extensively. I see no reason to limit using iterators defined in STL, nor
> implementing simple iterators for our custom classes. But creating very
> complex iterators may not classify as "simple C++".
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gromacs.org_gmx-developers