- changed component to mathengine
- changed milestone to 0.12
Add more non SI units
Now that we officially support units, we need more of them.
Obviously we need imperial measures (foot, mile, ...).
About SI prefixes: I think it is kind an elegant way to have them defined separately, like mega = 1e6
. I can then write 10 mega newton
(agreed; the space looks slightly awkward) and it will just work. I don't see a reason why we should include tons of redundant units like centimeter, milligram. Let the user to this if she'd like to use this notation.
This might also be a good point to consider #570. From the engine's perspective, constants and units would be the same. Maybe add a better way to configure builtin constants.
Temperature is not an option just yet. Non linear units are not handled by the current system (and won't be). The problem lies in expressions like:
30 celsius - 10 celsius
What did the user mean ? 20 celsius
? Probably. But what about 30 celsius - 10 celsius = 303 kelvin - 283 kelvin = 20 kelvin
? You get my point.
Comments (14)
-
reporter -
Hi Pol,
Thank you so much for adding units support for Speedcrunch. I have been waiting for units support on Speedcrunch for so long. I am so glad it is finally happening.
2 questions:
-
What is stopping you from having units symbol as well such as km, m, in, K, MJ, N...?
-
Have you consider using the definitions file of GNU units? It is quite an extensive file.
Really good work.
-
-
reporter Thanks Bob, glad you like it.
Of course I considered using the more concise symbol instead of full names. But there are two reasons why I opted against it.
- Ambiguity. Will 'nm' be a nanometer, or a nautical mile? There are more examples of this sort.
- Namespace crowding. If we'd indeed go ahead on implementing every unit we can think of, we will likely take up a sizeable part of all one- and two-letter names. We currently don't allow redefinition of builtin names, so the user would no longer be able to use those for their own purposes.
I am aware of GNU Units. Their list is enormous, with thousands of entries.
Anyway, you are able to define your own units: type
m = meter
, and save yourself some typing. Still the results will by default be displayed as multiple ofmeter
.@heldercorreia, @fk, @thadrien, @teyut What's your opinion on this matter? Shall we support m for meter, etc?
-
reporter I just had on more idea, by looking at how GNU Units does handle prefixes. Instead of defining one builtin variable per unit, we could have the evaluator just handle the usual constants (like pi) and user defined variables. If it cannot resolve a name that way (e.g.
km
), it passes it to a unit parser. The unit parser knows about prefixes and such, and can thus resolve a broad spectrum of names.If the user defines a variable or function with the same name as a unit, the user's value will automatically take priority (the unit parser is never invoked). Downside: we cannot auto suggest any of the combined unit names, since there is no list per se.
Maybe a combination of both methods (i.e. a list of core (spelled out) units + automatic parsing of the rest)? Or rather stick with enforcing prefixes to be spelled out?
-
repo owner I actually like the flexibility provided already. It's not a lot of work to define (once)
m = meter
. I do think that we should provide all units spelled out by default, e.g.centimeter
andkilogram
(right now we don't). The user would then do (once, if so wished)cm = centimeter
. If we start defining e.g.m = meter
by default, then things like issue#488and https://en.wikipedia.org/wiki/Metric_prefix#List_of_SI_prefixes get into trouble. I think that maybe it works well if we provide the metric prefixes spelled out by default, i.e.milli
,giga
, etc. This way, one could even easily definecm = centi meter
,kg = kilo gram
, etc. -
reporter - changed title to Add more non SI units
-
reporter What is the desired naming convention for units?
metricTon
,metric_ton
,metricton
,...? -
repo owner I'd say
metric_ton
. -
reporter Good. That's my favorite as well.
-
reporter One more decision about the naming scheme, then I'm done with this: consider for instance
UK_gallon
andUS_gallon
(which are surprisingly different). I could alternatively name themgallon_XX
. The former would allow an experienced user to be faster (just typeUK_ga
and let the autocompleter do the job), but for a new user it might be a bit troubling, as when typinggallon
, no hints will be given that actually a prefix is required. -
repo owner Is that how the units are actually officially called? US/UK Gallon? Why not provide us_gallon, uk_gallon, gallon_us and gallon_uk?
-
reporter Add aliases? That would work.
-
repo owner -
assigned issue to
-
assigned issue to
-
repo owner - changed status to closed
See pull request #51.
- Log in to comment