Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Generate meaningful labels for common units (#334)
Formerly, the common unit for, say, `"m"` and `"in"`, would get a label something like `"COM[m, in]"`. This is correct, but useless. First, to know what the unit _actually is_, the end user has to do some math: they have to find the largest unit that evenly divides all inputs. And then there's no easy way to check whether they got the math right! Now, we do the math for you. The new label corresponding to the above example would be `"EQUIV{[(1 / 127) in], [(1 / 5000) m]}"`, or something like it. `EQUIV{...}` asserts to the reader that everything contained therein is quantity-equivalent. Pick any argument, and you'd get a true statement. Interestingly, it can happen that the number of units that should _show up in the label_ is **different** from the number of units _in the common unit_. If we have two different scaled versions of the same unit, then both should show up in `CommonUnit<...>`, but only one should show up in the label `"EQUIV{...}"`, because the scaled versions will necessarily be identical after they're re-scaled to fit the common unit. Therefore, we remove redundancies, and if only one unit remains, we drop the `"EQUIV{...}"` shell. Helps #105. We still need to do a little better. First, if the _label_ has only one unit, then we should just use that _instead of_ the common unit! And second, we need to handle the common _point_ units.
- Loading branch information