Gather factors and add labels for scaled units #332
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First, when multiplying a
ScaledUnit
by another magnitude, we now foldit into the existing magnitude of the scaled unit. Previously, we'd end
up with
ScaledUnit<ScaledUnit<U, M1>, M2>
, and so on. We also nowomit any "trivial" scaling factors, whether because we're scaling by
mag<1>()
, or (more commonly) whether we've applied a bunch ofdifferent scale factors and they all cancel out.
(We did need to tweak a few cases that were relying on
U{} * mag<1>()
being meaningfully different from
U{}
.)Next, we now auto-generate labels for
ScaledUnit
specializations. ForScaledUnit<U, M>
, ifU
has label"U"
, andM
has label"M"
, wegenerate a label
"[M U]"
--- or, if"M"
contains an exposed slash"/"
, we'll generate the label"[(M) U]"
for lack of ambiguity. Thisresolves the vast majority of
[UNLABELED_UNIT]
labels. The remainingwork on #85 is simply to generate labels for a wider variety of
magnitude label categories.
Finally: we formerly had no way to decide ordering between units that
are both specializations of
ScaledUnit
, which do have identicaldimension and magnitude, and yet are not the same unit. (For
example, something like
"[(1 / 4) ft]"
and"[3 in]"
.) This may havebeen somewhat obscure in the past, but with the upcoming work on #105,
it's about to become very common. We added a test case that exposes
this, and then updated our ordering code to handle this case.
Helps #85. Unblocks #105.