Design solution for decibels and other "log-scale" units

[chiphogg]

This is a long-standing wish list item. We have some Aurora-internal design sketch notes which we could build on, but such as they are now, it's not really enough to begin in earnest.

The first step would be to propose the set of APIs by writing a series of usage examples. We would need to pay special attention to the distinction between "power" and "root power" units. Apparently, "decibel" encodes a different ratio depending on the dimension of unit it's applied to! Whatever APIs we design would need to satisfy this common usage while, critically, remaining "hard to use incorrectly".

We would also need to adhere to our library's core principle to avoid changing the values we store unless users explicitly request a conversion. For example: although I don't know the full set of API examples that would constitute an acceptance test, I'm pretty sure this is one of them:

EXPECT_THAT(deci(bels)(1) + bels(2), SameTypeAndValue(deci(bels)(21));

And this should be possible without ever leaving the integral domain. Explicitly, I want to rule out any solution candidates which convert the log-scale value to linear to store it.

This issue isn't likely to be the place where this design gets resolved; it's much too thorny a problem for that. We'll need to either make a Google Doc design doc, or else enable Discussions on this repo. Rather, the point of this issue is to say "yes, we're aware we don't have this; we have some ideas and plan to do it, but won't likely have time to get to it really soon".

[anurag22485]

Hi, is there any update on this? When can we expect support for dB?

[chiphogg]

For this, the implementation isn't the hard part, as far as we know. The hard part is figuring out what to implement: what interfaces should exist? I think the original post does a good job of explaining what I mean by that.

In practice, what's blocking progress is that we need to gather use cases from experts who use a variety of logarithmic units, in a variety of ways, in their day jobs. The goal is to produce a grand unified suite of test specifications that would show what results a correct implementation would produce. Crucially, we don't even know if this is possible yet. It may be that the distinction between power and root power quantities creates too much inconsistency for library interfaces. That's what the grand unified suite would solve:

• If the test cases are mutually consistent and coherent, great! We'll go make them pass.
• If the test cases aren't, then that sucks, but at least we'd have a crisp explanation for why we wouldn't implement them.

Note, too, that this "grand unified suite" isn't just an Au thing. mp-units is blocked on this as well (tracked in mpusz/mp-units#35). The "grand unified suite" would be a somewhat conceptual and library-agnostic thing.

I had thought we explained all this in P3045, but in checking P3045R6, I don't see it --- it looks like it's "TBD". 😅 So I'll put the explanation in this comment for now.

Finally, to answer your last question directly: we don't have any bandwidth to drive this suite forward right now, so I don't think we would do any work on this before the 0.6.0 release is out: thus, this wouldn't come any sooner than 0.7.0, likely sometime in mid-2026, and it could be later. But if somebody else got the (multi-units-library) test suite moving forward, then that would make it more likely for us to get to this sooner.

Hope that helps!