-
Notifications
You must be signed in to change notification settings - Fork 32
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
Can't normalise to SI units or handle common units #16
Comments
As to the first, yes, you have to be explicit.
|
Thanks, after my brief reading of UCUM I came to the conclusion it was a well intentioned but ultimately useless "standard" for common use cases since your average joe isn't going to use those conventions to describe a common length measurement like feet and inches. I guess it works really well for the tiniest minority in the world who deal with femto scale mass units. |
I agree, UCUM (and by extension Unitwise) is built to encompass a huge scope of units. That is obviously useful for say fluid dynamics and heat transfer. There are probably some things I can do to make it more useful for simpler use cases (like perhaps only loading more common units by default). In any case, thank you for your feedback. I've got some things to ponder. |
There does not seem to be an obvious way to normalise units to their SI counterpart.
I was expecting if I did
Unitwise(3, 'foot')
I would be able to do ato_si
without having to know the dimension type a-priori. I was wanting to use this library for units handling and normalise all units regardless if they be length, mass, area, volume, etc before storing in DB but it seems not possible the way things are currently structured.Also I noticed
Unitwise(3, 'ft')
on closer inspection seems to return mass, not length, making use of this library for common use cases rather impractical.The text was updated successfully, but these errors were encountered: