Mike Boutin

Thanks for the PR! I started the automated checks and will try to review today.

I've gotten through the first few files in my review so far. * Why use `1.0/6.022_140_857e23` instead of `1.0/6.022_140_76e23`? Floating point precision issues? * I've included a diff below of...

Thanks for submitting this issue. This is a good idea. I'm trying to get through the PR backlog so it will be a bit before I could get to this....

Short answer is that `Kind`s are messing things up. Adding an `.into()` to the `reduce` fixes the problem. ```diff - .map(|x| x / total_weight) + .map(|x| (x / total_weight).into()) ```...

* If `total_weight` is `0` you'll get a `NaN` or divide by zero error. * I take it you intended the return to be `Option`? Everything else looks reasonable. Will...

Thanks for the PR! I'll review in detail over the next few days. In regards to the `Mul` impl the problem is that the `Kind` associated type defaults to `uom::Kind`....

Only implementing `Mul` and `Div` for `Kind = uom::Kind` would require way too much work to implement a custom kind (10 `Mul` and `Div` implementations multiplied by all of the...

This is definitely moving in the right direction. My biggest concern so far is duplicate code. The code base already has near-duplicate implementations because of `autoconvert!`. Can these be merged?...

I've been doing some investigation and believe we can eliminate all of the duplication, include the existing duplication for `autoconvert`. Since [1.13.0](https://github.com/rust-lang/rust/blob/master/RELEASES.md#language-48) macros are allowed in the type position. This...

That sounds like a good way to start to me. I would just make sure that you include all the parameters that will eventually be needed (`$($U)`, `$Vl`, `$Vr`). ```rust...