Jacek Generowicz

> While looking at the latest question I realized a [`recip`](https://docs.rs/uom/latest/uom/si/struct.Quantity.html#method.recip) method is already defined when `V: Float`. If your code meets that constraint you can just use recip instead...

> Is there a convenient way of defining ad-hoc `Quantity`s such as `PerLength`? Can I do better than this > ```rust > use uom::si::{ISQ, SI, Quantity}; > use uom::typenum::{Z0, N1};...

Of course, it is possible to do something like ```rust use uom::si::length::meter as arbitrary_conversion_unit; Ulength::new::(b.get::() as usize); ``` but I'm hoping that there's a less ad-hoc, higher-level approach available.

One one occasion, IIRC, the *only* relevant information anywhere in the error message was the presence/absence of a single `&` buried deep inside the ``s of two different parts of...

`tnfilt` (at least the slightly patched version I submitted in a PR (it looks like rustc has changed the amount of qualification in shows in the error messages, since `tnfilt`...

I think that there are two separate concerns here, which both use the word 'vector', with different meanings, and we should be careful not to confuse: 1. Scalar vs vector:...

Which is why I was hoping that the `Frame` mentioned in another issue here does indeed refer to frames of reference, and somehow caters for this. BTW, I ended up...

> Do you have any kind of intuitive sense at this point the right point to add this abstraction? I'm afraid that I'm not yet sufficiently familiar with the structure...

I don't have a preference. I've been using `assert_approx_eq` but can't remember why I chose it. It was probably the first one I tried and it let me get on...

I've taken [`float_eq`](https://crates.io/crates/float_eq) for a quick spin. First impressions very good. I'll probably use it instead of `assert_approx_eq` from now on. Following your suggestion, this macro ```rust macro_rules! assert_uom_eq {...