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

Suggestion: use thousands of kilometres instead of "megameters" by default #1452

Open
zcohan opened this issue Mar 25, 2019 · 5 comments
Open
Labels

Comments

@zcohan
Copy link

zcohan commented Mar 25, 2019

At present:

1001 km = 1.001 Mm //megameters

I understand why MathJS evaluates the expression this way, given the standard SI prefix system for metric units.

However, scientists & regular people are much more likely to use thousands of kilometers than megameters. It would be nice if MathJS could make a practical exception from jumping to the next largest SI unit in this case.

@josdejong
Copy link
Owner

Yes that's true, we don't use megameters in practice. Makes sense to me to make a special rule for this in the function that finds the "best" prefix.

I'm thinking about whether there are other units which have a similar case. Maybe time in seconds? (I don't use megaseconds but I do use milliseconds for example?). More ideas?

@bornova
Copy link
Contributor

bornova commented Mar 25, 2019

Also:

1001 kg = 1.001 Mg

Implementing #1314 would be nice and could address this issue as well :)

@mgsternberg
Copy link

Also:

1001 kg = 1.001 Mg

In most contexts (scientific, civil engineering, except perhaps for astronomy and particle physics), I would expect that to be communicated as 1.001 t tonnes (metric tons).

@ericman314
Copy link
Collaborator

The km versus Mm issue is resolved by UnitMath's commonPrefixes property for each unit, m in this case.

Choosing between kg and t is a little more subjective in my opinion, it could go either way. Possibly we could include a method that converts a unit to a different related unit of a more appropriate magnitude, but I don't think we would be able to meet everyone's expectations perfectly.

@gwhitney
Copy link
Collaborator

gwhitney commented Oct 6, 2023

We need a place to house all these unit things until there is a good long-term way to deal with them. In any case, the points raised here are all still valid.

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

No branches or pull requests

6 participants