[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [h5md-user] Specifying the data type
From: |
Olaf Lenz |
Subject: |
Re: [h5md-user] Specifying the data type |
Date: |
Thu, 29 Aug 2013 17:20:16 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
On 08/29/2013 01:46 PM, Felix Höfling wrote:
> But in general, we want to allow also (custom) data of Composite
> type, namely Array, Enumeration, Variable Length, Compound. Quite a
> long list ...
That is why I would prefer the explicit names ("Integer") instead of
single characters ("I").
In some cases, the composite types are declared by special notations.
We already have notations variable lengths ([variable]). For
enumerations one could think of something like ("[enum (0: periodic,
1: open)]") or the like, and compounds would probably be expressed
structurally, as they are pretty similar to a group.
> Does it make a difference with respect to reading whether positions
> are stored as Float[N][D] or as Array[N], where the Array type is
> a D-dimensional vector?
Ooops, I wasn't aware that Arrays are not the same as datasets.
> - I would not put a restriction on the type of String, whether
> fixed-size or variable size. The reader has to handle both cases
> (although this means some extra effort on the reader).
But in some cases it may have to be restricted. For example, the
various PDB fields have a fixed size (in best FORTRAN-style).
> - the type of the position is actually restricted to be Atomic
> (see above) and to the domain of real numbers, i.e., Float or
> Integer.
What happens in hdf5 if you try to read something written as an
integer datatype using a float type?
> - something similar happens with the particle species: it could be
> Integer or Enumeration
There, the nice thing is that you can always read an enumeration as an
integer.
> In conclusion, putting the HDF5 datatype class to the graphs may
> help to detect possible issues. But is should happen
> typographically in a modest form and allow for multiple datatype
> classes. I suggest to introduce our own abbreviations, which can
> easily be combined:
I am all for explicit long names, as they are much better to read.
> <particle_group> \-- box \-- (position) | \-- value:
> Float/Integer [variable][N][D] | \-- step: Integer [variable] |
> \-- time: Float [variable] \-- (species): Integer/Enumeration [N]
Olaf
- --
Dr. rer. nat. Olaf Lenz
Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
Phone: +49-711-685-63607
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlIfZrAACgkQtQ3riQ3oo/pXAgCePiYTRyL62use/0WtFRKSL8hx
fKUAoLQNhGVeho0oshTDRwbujw2duMUl
=QCTg
-----END PGP SIGNATURE-----