Design decision: easily parsable unit definitions

[avirshup]

This is a consequence of the requirement that all quantities include units - #2

Anyone parsing the file format will need to be able to parse the physical units of all the numbers, so there needs to be an agreed-upon standard.

This is easy for names like angstrom or eV. It becomes more complicated for units like angstrom/eV or fs^2/hectare - and ideally, we don't want to require anyone supporting this format to have to write their own mathematical parser.

[avirshup]

From @jchodera on Slack:

• UNIDATA Units seems pretty standard, except their webpage is down: http://www.unidata.ucar.edu/software/udunits/
• Boost Units for C++: http://www.boost.org/doc/libs/1_61_0/doc/html/boost_units.html
• math.js has its own units handler, though I wonder if this might actually be compatible with pint: http://mathjs.org/docs/datatypes/units.html

[avirshup]

Another possibility is to require units in the form {unit1:exponent1, unit2:exponent2, ...}, e.g.

{...,
 velocities: {value: [ [1,2,3], [-1, -2, -3]],
              units: {'angstrom':1, 'femtosecond':-1}},
 ...}

I like this only because it doesn't require anyone to parse mathematical notation.

[davidlmobley]

I'll revisit this later, but I had to chuckle at square femtoseconds per hectare...

[egonw]

The QUDT ontology may fulfill this and has the math in the ontology to make unit changes, e.g. convert fs to s... the Java library jQUDT does that.

[davidlmobley]

Another possibility is to require units in the form {unit1:exponent1, unit2:exponent2, ...}, e.g.

@avirshup - that seems acceptable to me if there are no other good alternatives; I don't know anything about the QUDT stuff that @egonw mentioned but it should be looked at, I think!

[egonw]

@davidlmobley see http://www.qudt.org/