Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fields defined in the dictionary which have units #34

Open
bruceravel opened this issue Aug 26, 2014 · 1 comment
Open

Fields defined in the dictionary which have units #34

bruceravel opened this issue Aug 26, 2014 · 1 comment

Comments

@bruceravel
Copy link
Member

This is one of a short string of issues I am opening up after doing some work on the specification document leading up to #28.

Should something like Mono.d_spacing be

  Mono.d_spacing = 3.13543 Angstroms

That is, should the unit be included. This would allow reasonable (and SI!) things like

  Mono.d_spacing = 313.543 picometers
  Mono.d_spacing = 0.313543 nanometers

with a unitless number

  Mono.d_spacing = 3.13543

interpreted as being in Angstroms.

@newville
Copy link
Member

I don't disagree with this, but the complication with units can quickly spiral out of control (pm, picometers, picometres, .1e-12 m, 1x10^-9 cm). Is the library supposed to validate units and return values with meaningful units (like, auto-convert to nano-feet) for all numbers, or just Mono d spacing?

Or, is the unit just a string? What unit strings are allowed? What about "Unicode 212B"? Do we need a separate dictionary of units?

There is a real need to have mono d-spacing -- it is used in the format. But having to recognize and act on units could easily double the size of the C function. Allowing one of ("Angstrom", "nm", "pm"), with a default of "Angstrom" might be a reasonable compromise, but that is not anything close to "handling units".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants