h5md-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h5md-user] [EXTERNAL] Re: Units Module Question


From: Konrad Hinsen
Subject: Re: [h5md-user] [EXTERNAL] Re: Units Module Question
Date: Tue, 13 May 2014 10:09:58 +0200

Hart, David Blaine writes:

 > I actually think you are right, and that the string "1.602 10-19 C"
 > is not valid.  I would take this reading because it is a "unit" and
 > not a conversion factor, which means I was misusing the "unit"
 > metadata when I was trying to give a conversion factor in my units.

Indeed.

 > But it would still make sense to have a single numeric unit
 > factor, especially a power of ten, as it is descriptive of the
 > units. It would then make sense not to allow scientific notation,
 > since that should probably apply to the data itself, while the
 > units module only defines the unit, not a conversion factor which

Speaking for my original unit definition in MOSAIC, on which the one
in H5MD is based, my original intention was indeed not to allow
scientific notation, in order to avoid the problems associated with
floating-point notation and precision. That's why the specification
allows only one numerical factor, and requires it to be an integer or
a decimal fraction. It makes it possible to compare units for identity
without doing floating-point operations.

A straightforward generalization that maintains this advantage is to
allow integers and decimal fractions written in an exponential
notation. A very simple specification would actually be "an integer
plus optionally an integer power of ten", thus banning the decimal
point which could be seen as an invitation to do floating-point
computations.

 > I realized this as I was reading the SI Brochure, and it seems the
 > units module has already accounted for this by defining the
 > "system" metadata within the /h5md/modules/units/ group. If I
 > wanted to propose a, for example, "CGS-ESU" system, that would be
 > easily defined as a different "system". And if I want to convert my
 > energy from Kcal to J, I should multiply through the 4.184 J / Kcal
 > conversion factor on my data first, then set the unit to "J",
 > rather than set the unit to "4.184 J", since that isn't a unit,
 > it's an equation. :-)

Right.

Again referring to MOSAIC, my intention was to explicitly limit the
number of allowed units, both for clarity and ease of processing.  If
you allow kcal, then sooner or later the multiple definitions of the
calorie will cause trouble. Even if you specify which calorie you want
to allow, someone will get it wrong one day. In the spirit of the SI,
the best solution in the long run is to ban all those messy units and
hope that they will finally disappear from science. Of course this
philosophy is in direct conflict with any approach trying to
accommodate a maximum of conventions in a single file format.

Konrad.
-- 
---------------------------------------------------------------------
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: research AT khinsen DOT fastmail DOT net
http://dirac.cnrs-orleans.fr/~hinsen/
ORCID: http://orcid.org/0000-0003-0330-9428
Twitter: @khinsen
---------------------------------------------------------------------



reply via email to

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