On Tue, Aug 16, 2011 at 07:53:30PM +0200, Felix Höfling wrote:
In NumPy, it doesn't make a difference, I think you wouldn't even
have to provide the index as it is now (except for beautification of
the output). But think about an analysis tool written in C++ (or
Fortran?), there it would cause a lot more troubles.
If we want to "allow" for this exception in H5MD, then both variants
have to be supported by a proper H5MD reader. This is taken for
granted in NumPy, but not necessarily in other languages. In
general, I feel that exceptions and alternatives make things more
difficult to maintain in the end.
I agree that a reader would have to support 1-dimensional datasets
both with and without the “extra” dimension, which would mean more
work for every author of a H5MD-compliant trajectory reader.
@Peter: I must be missing something here. In HALMD, we would
instantiate the templates with dimension=1 resulting in
vector<fixed_vector<double, 1> >
Otherwise, we would have to make use of type traits in a more
consistent manner.
What I meant to say is that if HALMD were a 1D-only package, and we
were using vector<double> for particle coordinate arrays, our current
H5MD writer would not add the extra dimension. But you are of course
correct, if we supported 1D in addition to 2D/3D, we would use
fixed_vector. Anyway, this is off topic on this list ;-).
So I made up my mind and would vote for a consistent data format that
mandates “position/samples” to be of dimensions (variable × N × D),
regardless of whether D is equal to 1, or greater. This adds only
little burden onto the author of a 1D simulation package, and spares
every author of a H5MD evaluation script a major headache.
Peter