Support for logarithmic units

[Atmelfan]

While not strictly supported by SI it's common in electronics and other industries to use logarithmic quantities expressed in Decibels such as dBm[W], dBuV/m.

It would be nice to have a decibel_<unit> (Ex: decibel_milliwatt) for these common usages which converts them to the linear base quantities or vice versa.

It would need to perform different conversion to power and field quantities (see below).

Power quantities (watt):

P = 10.powf(Lp/10)*P0
Lp = 10*log(P/P0)

Field quantities (volt, ampere etc):

F = 10.powf(Lf/20)*F0
Lf = 20*log(F/F0)

Where:

• F/P = Linear quantity
• Lf/Lp = Logarithmic quantity in decibel
• F0/P0 = Reference quantity.

Usually the reference is provided as a suffix behind dB, e.g. dBuV => F0 = 1uV.

The simple decibel (dB) and derivatives (dBi etc) would also be applicable as a Ratio unit.

The Bell (B) and Neper (Np) could also be supported but nobody cares about those.

Not sure how hard this would be to implement as it would not be a simple coefficient and offset.

A reasonable alternative would be a special functions like new_db::<reference>(logvalue) and get_db::<reference>() but would not be as versatile and consistent.

If I can understand how all the macros and generics works I'll try to implement something...

[iliekturtles]

I've only briefly looked at the problem so far. I think what would need to be done is to pull conversion formulas (from_base, to_base, change_base) into Conversion<V> (or sub-traits). The default could still do a linear conversion, but certain units could override the default calculation with more complex formulas.

[igiona]

I see that @iliekturtles you added some more changes to @Atmelfan PRs in #310 but never merged.
Is there an update or plan for this feature?

[iliekturtles]

#229 (comment)

Logarithmic units require pow/root functions which are not available in no-std/no-libm builds. Excluding logarthmic units has proven difficult (in-place filter foiled by macros unable to be used inside an enum definition). Using a tt-muncher could possibly solve the issue, but would likely hit the recursion limit very quickly and likely the quadratic performance characteristics would make uom's slow compilation even slower.

I just haven't had a chance to get back to this since then.