mp-units drafts a type-safe design for dB, dBm, Np, pH before coding it

Logarithmic quantities like dB, dBm, Np, and pH are everywhere in engineering, yet no general-purpose units library models them correctly. nholthaus/units lets dBW_t(10.0) + dBm_t(40.0) compile into a meaningless '20 dBW', and Python's pint defines dB only for power, leaving voltage and current gain factors entirely up to the user.

The mp-units team has published a design that separates 'levels' (absolute points like dBm, anchored to a reference) from 'gains' (deltas like dB or Np). The arithmetic follows: level + gain = level, level - level = gain, and level + level is ill-formed. The quantity kind carries whether a factor is power-based or root-power-based, so calling .linear() on a +6 dB voltage gain correctly returns 2.0 while a power gain returns ~3.98 — and the type system prevents applying a voltage gain to a power level.

One mechanism is meant to cover RF, audio/DSP, acoustics, musical intervals (octave, cent), information theory (Sh, nat, Hart), pH, and stellar magnitude, while staying aligned with the upcoming IEC 80000-15:2026 standard.

Rather than implement first and fix bugs later, the authors are asking domain experts to review the design and weigh in on six open questions — including how log(0) should behave (IEEE -inf, a thrown error, a distinct error type, or a unit-specific sentinel like the -400 dB floor used in real DSP code) and whether a level should print as the industry-standard '10 dBm' or the ISO-conformant '10 dB (re 1 mW)'.