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

[Roland Schulz]

On Tue, Feb 5, 2013 at 3:21 PM, David van der Spoel <spoel at xray.bmc.uu.se>wrote:

> On 2013-02-05 20:59, Roland Schulz wrote:
> >
> >
> >
> > On Tue, Feb 5, 2013 at 2:33 PM, Teemu Murtola <teemu.murtola at iki.fi
> > <mailto: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.
>
> Looking at http://www.cplusplus.com/reference/stl/
>
> To be on the safe side we can/should probably limit ourselves to C++98?
>
Yes. Unless can also be made available to C++03/98 (same thing), like
shared_ptr and gmx_unique_ptr and is approved.


> But is this the same as the example I mentioned using
>
> std::vector<MyClass>::iterator ?
>
Not sure what you mean. ConstArrayRef (
http://jenkins.gromacs.org/job/Doxygen_Gerrit_master/javadoc/html-full/classgmx_1_1ConstArrayRef.html)
is written by Teemu and gives a C++ interface (including iterators) to a
standard c array. So it isn't part of the stl but behaves mostly like a
readonly std::vector.

Roland


>
>
> >
> > Roland
> >
> >
> >
> > --
> > ORNL/UT Center for Molecular Biophysics cmb.ornl.gov <
> http://cmb.ornl.gov>
> > 865-241-1537 <tel:865-241-1537>, ORNL PO BOX 2008 MS6309
> >
> >
>
>
> --
> David van der Spoel, Ph.D., Professor of Biology
> Dept. of Cell & Molec. Biol., Uppsala University.
> Box 596, 75124 Uppsala, Sweden. Phone:  +46184714205.
> spoel at xray.bmc.uu.se    http://folding.bmc.uu.se
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
>
>
>
>


-- 
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/af54ffdb/attachment.html>