[gmx-developers] Some thoughts about new trajectory analisys api

[Roland Schulz]

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:
>>> "std::copy(sel.xBegin(),sel.**xEnd(),out)".
>>>
>>
> 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
replacement/extension.


>   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.**
>> php?title=Developer_Zone/**Programming_Guide/Allowed_C%**2B%2B_Features<http://www.gromacs.org/index.php?title=Developer_Zone/Programming_Guide/Allowed_C%2B%2B_Features>
>
>
>  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++".
>

I agree.

Roland



-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130205/f86d94e5/attachment.html>