You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
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
beThat is, should the unit be included. This would allow reasonable (and SI!) things like
with a unitless number
interpreted as being in Angstroms.
The text was updated successfully, but these errors were encountered: