h5md-user
[Top][All Lists]
Advanced

[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-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]