For some reason, MSVC seems to want to instantiate these, even though
nobody ever asks for them (as evidenced by the fact that the builds
passed on other architectures).
This commit is huge, but hopefully the cognitive load is not too bad.
The bulk of this commit is just some fairly mechanical updates from
`ratio` to `Magnitude`. Other things to call out:
- `UnitRatio` goes away. We don't need this concept, because Magnitude
can't even _represent_ anything that doesn't satisfy it.
- I commented out some formatting test cases where the precise
expression changes, but the number is completely equivalent. We will
need to decide how we want to handle Magnitude formatting as a
separate, follow-on task. But at least Magnitude gives us all the
tools we'll need to do so!
This resolves a TODO and lets us use arbitrary exponent denominators.
I also attempt to clarify the semantics. This is based on my best
effort of understanding pre-existing concepts in the library, so I hope
I got it right!
We provide two new functions, `numerator(m)` and `denominator(m)`, for a
Magnitude `m`. They fulfill the following conditions:
1. `numerator(m)` and `denominator(m)` are always integer Magnitudes.
2. If `m` is rational, then `m == numerator(m) / denominator(m)`.
If `m` is _not_ rational, then the numerator and denominator are not
especially meaningful (there is no uniquely defined "leftover irrational
part"). However, we choose a convention that matches how humans would
write a mixed number. For example, sqrt(27/16) would have a numerator
of 3, denominator of 4, and a "leftover part" of sqrt(3), matching the
"human" way of writing this as [(3 * sqrt(3)) / 4]. This has no use
yet, but it may later be useful in printing the Magnitude of an
anonymous Unit for end users.
To further reduce friction for the upcoming migration, we provide an
implicit conversion from a Magnitude to a `ratio`. We restrict this
operation to rational Magnitudes, and guard this with a `static_assert`.
This stems from an earlier mistake where I was using primes in the first
wheel, rather than coprimes-to-the-basis. 1 is not prime, so we used to
need to handle it separately (in an implementation which was, to be
clear, wrong). It _is_ coprime, so now we get it for free!
I verified that we hit GCC 10's constexpr limit with
`wheel_factorizer<1>`, but pass with `wheel_factorizer<4>`. I hope this
number is enough smaller than the square root of the previous value that
the other compilers will be able to handle it. If not: we'll go lower.
Mateusz Pusz
Chip Hogg
Markus Hofbauer
Johel Ernesto Guerrero Peña