mp-units/HEAD/blog/2026/07/24/introducing-logarithmic-quantities-and-units/

[giscus[bot]]

mp-units/HEAD/blog/2026/07/24/introducing-logarithmic-quantities-and-units/

The quantities and units library for C++

https://mpusz.github.io/mp-units/HEAD/blog/2026/07/24/introducing-logarithmic-quantities-and-units/

[paweltrella]

Context about myself: I am an audio software developer working heavily on acoustic measurements, so I deal with all kinds of decibels daily. I have a strong preference for MATLAB and Python. C++ is my fifth language by usage, so please read my comments from that perspective.

1. The first code example in the article is not ideal

Looking at your opening example, it is hard for me to get the point, because it is hard to understand what the purpose of such a line of code would be:

auto half_voltage = (0.5 * V) * (6.0 * dB).linear();

It requires guesswork about what is happening under the hood.
I assume one of the goals of the article is to fix your own motivating example.

This pair would make the point faster:

auto my_power   = (0.5 * W) * (6.0 * dB).linear();   // 0.5 W * 4 ≈ 2 W, RIGHT
auto my_voltage = (0.5 * V) * (6.0 * dB).linear();   // 0.5 V * 4 ≈ 2 V, WRONG

The same expression, the same 6.0 * dB, correct for the watt and wrong for the volt. In my opinion this should be followed by - or the article should close with - a final proposal showing how to write the same thing correctly using mp-units:

auto my_power   = ((0.5 * W).log_in(dBW) + 6.0 * dB).linear();   // 0.5 W * 4 ≈ 2 W, RIGHT
auto my_voltage = ((0.5 * V).log_in(dBV) + 6.0 * dB).linear();   // 0.5 V * 2 = 1 V, RIGHT

If this is not how it works right now, then I suggest resolving the gain's domain at the point of application.

2. Summing two levels: right decision, wrong rationale text

level + level | ill-formed | not one operation, linearize to combine

"Linearize to combine" is misleading and I would change it. If linearizing were all that is needed to combine, why would it not simply be handled in the background for the user? It is not, because linearizing and summing is only correct for uncorrelated sources.

In my opinion this should remain a compile-time error. But something like "combining levels depends on correlation and phase, which are not recoverable from the levels alone" is the accurate statement, and it is a stronger argument for ill-formed than the current wording: it says the operation is underdetermined, not merely inconvenient.

3. dBFS is barely specified

The article never says which full-scale convention is meant - peak sine versus full-scale square wave (the 3.01 dB AES17 offset), nor peak versus RMS. Given your own rule that each distinct reference needs its own unit symbol, this arguably needs dBFS and dBFS (AES17) as separate units. In my opinion this is critical.

Personally I do not like the AES17 convention, but it is the one most used in the industry. There is also the concept of dBov as a separate unit alongside dBFS, precisely to be explicit about the full-scale convention. See the "RMS levels" section of https://en.wikipedia.org/wiki/DBFS.

4. Sensitivity looks like a first-class kind

In my work it is critical to be able to define multiple sensitivity units and to chain them to calculate values:

dB(V/Pa) · dB(Pa/V) · dB(FS/Pa) · dB(Pa/FS) · dB(V/FS) · dB(FS/V)

Direction matters, and it matters differently depending on whether we are talking about microphones or speakers, inputs or outputs, and so on.
Great job here!

The whole thing looks great!
I hope that helps,
Pawel

[mpusz]

Thank you, this moved four things in the article. Also, sorry for the late reply, but I was on a long trip, and I am just catching up with work.

1. The opening now uses your pair, and Gains carry their domain closes the loop with the corrected version. One fix to your snippet: there is no domain-less dB in this design, so it reads 6.0 * dB<isq::power> and 6.0 * dB<isq::voltage>, and no round trip through the log domain is needed. Your "resolve the gain's domain at the point of application" is now Open Question 8, quoted and credited to you. You are the right person to settle it: when your code stores a gain and applies it later, is naming the domain at construction a help or an obstacle?

2. Changed, using your argument. The table now reads "underdetermined, depends on correlation and phase", and the note states that the phase is not recoverable from the two levels alone.

3. You were right that this was critical, and my first attempt at fixing it was wrong, so Digital audio full scale is a new section. Both references are modeled: dBov for full scale (a full-scale square's RMS equals its peak, so this is also the origin a DAW peak meter uses) and dBFS (AES17) 3.01 dB below it. What I could not settle from your comment is the bare symbol. You list dBFS as a unit separate from dBFS (AES17), which gives it the full-scale origin, but you also say AES17 is what the industry mostly means by dBFS. The article currently defines no bare dBFS at all and leaves an application to alias whichever it uses. Which origin should it carry, if it should exist?

4. This is now Open Question 7. Defining the units was the easy half, as you say. Chaining works today only by crossing to linear, which is correct and verbose. The log-domain form you would write on paper needs level + level across two different kinds, constrained so the multipliers agree (dBV + dB(A) would otherwise give exactly twice the right dBW). We have no preference here: is the operator worth having, given that + reads as superposition to one group of users and as a transfer function to another? And separately, how often do you need the reciprocal direction, dB(V/Pa) to dB(Pa/V), which has no spelling today either?

[paweltrella]

Thanks for response.

1. My preferred option would be Option B - Domain at the point of application. With gain is a plain log which could be reused across different domains.

2. Table. Looks OK.

3. dBFS definition.
   My understanding is there are two definitions of dBFS. Both definitions can be applied to RMS values or to peak sample values.

   • Full scale sine wave as a reference value for 0dBFS.
   • Full scale square wave as a reference value for 0dBFS.

   First one is followed by more standards (including AES-17), even though second one is IMO second one is more "mathematically" correct.
   Various software including DAWS uses various conventions. Some even provide option to select dBFS reference in the user preferences.
   Some people claim using dBFS term when dealing with square wave based definition is incorrect. Some people don't care about it and do it either way.
   Some software is not saying "dBFS" anywhere and just use plain "dB" relative to unknown reference which IMO is the worst possibility.
   IMO the clean solution is to use dBFS with "sine wave" definition and dBov when dealing with "square wave" definition. In every case it must be clear in the documentation.

4. Sensitivity chaining.
   I was just making a point that current implementation is great, and I was not seeing any issues with the implementation at that moment, nor now. But answering your questions - having a flexibility to define sensitivity in both directions separately like dB(V/Pa) and dB(Pa/V) is preferred over having it defined only in one-way, because it depends on whether someone is dealing with input or output sensitivity, or microphone or speaker transducer, ADC or DAC. Chaining sensitivities also is needed as for example one can have a speaker transducer of a given sensitivity (usually represented in dBSPL at 1m but in reality it is dB(20uPa/V) at 1m) connected to a smart amplifier of a given nominal output sensitivity (dB(V/FS)), all fed with a digital signal with level of X dBFS and when you want to know what will be resulting in-air level at a given distance.

I hope those inputs are helpful,
Best
Pawel

[chiphogg]

I'm excited to read this article --- looks like amazing progress on a sorely needed issue! I'm only partway through so far and I think I'll have to finish it later. I'm looking forward to digesting this and getting dB support added to Au in an upcoming (although definitely post-0.6.0! 😅) release. I've already seen that you tackle power vs. root power head on, which is very encouraging.

I did want to let you know that the nholthaus unit test example doesn't seem entirely fair. It's from the archived 2.x branch of the library. The main branch is now for the 3.x series, and although I could be mistaken, I believe @nholthaus had already fixed the specific issue in the example.

It seems most likely to me that the mistake was entirely innocent. The 3.x branch cutover was just a few weeks ago. Au recently had to update our alternatives guide in response to this change, and to the amazing flurry of other changes (a 100+ issue backlog, completely cleared in a matter of days!). So I assume you simply wrote most of this article (including that part of it) a while back, and finished it later, without realizing that the example had become obsolete by the time it was published.

Anyway, just wanted to let you know. Excited to read the rest of the article! Not sure when I can finish it, but it looks impressively thoughtful and comprehensive.

[mpusz]

You are right, thank you. The example is pinned to the archived 2.x branch, and 3.x main deletes dBW + dBW and documents the same rule set we propose. The prior art section now describes 3.x, credits the fix, and keeps only what still differs: decibel_scale hardcodes 10 * log10 and UNIT_ADD_DECIBEL is instantiated for power only, so there is no root-power path; the level/gain split rides on the dimension rather than on an origin-carrying point type; and there is still no neper or frequency-interval unit.

For the record, the change landed on 2026-08-17, three weeks after this article went out, so no assumption about when we wrote it is needed.

One thing worth relaying upstream: docs/explain/scales.md on main still documents dBW + dBW yielding 6 dB with a squared dimension, so that page now contradicts the deleted operator. When you get to the open questions I would value your read on 6 in particular, whether the power/root-power classification should default or be mandatory, since it is the same call you will face in Au.