Tweak Gain arithmetic #463
Conversation
For gain the negation gives the negative gain, consistent with arithmetifc operations operating in the logarithmic domain. For level, negation is disallowed, consistent with treating level as a linear quantity in most contexts. Fixes PainterQubits#429
This tweaks gain arithmetic, by making both `Gain` and `Level` either purely linear or purely logarithmic, semantically. `Level` was already mostly linear, with a few minor exceptions that were removed here. `Gain` was previously logarithmic for purposes of `+`,`-` and linear for purposes of `*`,`/` (i.e. both sets of operations were equivalent - PainterQubits#461). This makes it purely logarithmic, i.e. `*` and `/` between Gains are disallowed. When arithmetic is mixed, only one of `(+,-)`, `(*,/)` is disallowed. Which one depends on whether the non-Gain unit involved is a Level (in which case `(+,-)` is used) or a regular Quantity (in which case `(*,/)` is used). Note that this design leaves all examples that are currently in the docs on this topic unchanged (though I did rewrite the docs to clarify the new semantics). I'll take that as a hint that this is a reasonable design that is not too breaking to people's expectations. I also think it's a lot more consistent. The primary advantage of doing this is that it'll allow us to reclaim other arithmetic operations like `*`/`/` on `Gain`, while being quite consistent. For example, I'm workign with an SDR that supports gains between `0.0dB` and `1.0dB` in its amplifier, in setting increments of `1/256dB` (linearlly spaced in dB space, i.e. logarithmically spaced). I'd like to represent this as `0.0dB:(1/256)dB:1.0dB`, but with the current definition of arithmetic, the definitions of range are unusable, because the arithmetic system is iternally non-consistent. This does not yet add those new operations, becuase some things (like `/(::Gain, ::Gain)`) would change meaning, so I'd like to give people a couple weeks to notice that things changed, but I'm hoping to do that in the future.
Codecov Report
@@ Coverage Diff @@
## master #463 +/- ##
==========================================
- Coverage 83.83% 83.53% -0.30%
==========================================
Files 16 16
Lines 1342 1336 -6
==========================================
- Hits 1125 1116 -9
- Misses 217 220 +3
Continue to review full report at Codecov.
|
| @@ -134,11 +131,11 @@ logarithmic quantity is: | |||
| Unitful.Gain | |||
| ``` | |||
|
|
|||
| One might expect that any gain / attenuation factor should be convertible to a pure number, | |||
| One might expect that any gain / attenuation factor should be convertible to a scalar, | |||
There was a problem hiding this comment.
I agree that “pure number” is not a good term here, but I also don’t like “scalar”. To me, scalar means “not a vector”, and even though that is technically correct (dimensionful quantities form a vector space), I think it doesn’t make this more clear. I would write “real number”, but I see that you replaced that as well. Can you explain why you prefer “scalar” over “real number”?
If we agree on “scalar” here, it should also be used in the first sentence in the “Constructing logarithmic quantities” section.
| does not make much sense. This is because `dB` acts more like a constructor than a proper | ||
| unit. | ||
| With a few exceptions, dimensionful logarithmic units, such as `dBm` behave just like the underlying | ||
| linear unit for purposes of arithmetic (i.e. arithmetic operations commute with `linear`). However, |
There was a problem hiding this comment.
linear is not yet introduced at this point, so users will not know what this means.
|
We should definitely fix the arithmetic to be more consistent. However, I would consider this a breaking change, and if we change |
|
Negating a julia> 2u"dBm" - 3u"dBm";
julia> show(ans)
ERROR: DomainError with -0.4103691225077659:
NaN result for non-NaN input. |
Co-authored-by: Sebastian Stock <[email protected]>
This tweaks gain arithmetic, by making both
GainandLeveleither purely linear or purely logarithmic, semantically.
Levelwas already mostly linear, with a few minor exceptions that were
removed here.
Gainwas previously logarithmic for purposes of+,-and linear for purposes of*,/(i.e. both sets ofoperations were equivalent - #461). This makes it purely logarithmic,
i.e.
*and/between Gains are disallowed. When arithmeticis mixed, only one of
(+,-),(*,/)is disallowed. Whichone depends on whether the non-Gain unit involved is a Level
(in which case
(+,-)is used) or a regular Quantity (in whichcase
(*,/)is used). Note that this design leaves all examplesthat are currently in the docs on this topic unchanged (though
I did rewrite the docs to clarify the new semantics). I'll take
that as a hint that this is a reasonable design that is not too
breaking to people's expectations. I also think it's a lot more
consistent.
The primary advantage of doing this is that it'll allow us to
reclaim other arithmetic operations like
*//onGain,while being quite consistent. For example, I'm workign with
an SDR that supports gains between
0.0dBand1.0dBin itsamplifier, in setting increments of
1/256dB(linearlly spacedin dB space, i.e. logarithmically spaced). I'd like to represent
this as
0.0dB:(1/256)dB:1.0dB, but with the current definitionof arithmetic, the definitions of range are unusable, because
the arithmetic system is iternally non-consistent.
This does not yet add those new operations, becuase some things
(like
/(::Gain, ::Gain)) would change meaning, so I'd like togive people a couple weeks to notice that things changed, but
I'm hoping to do that in the future.
cc @sostock - let me know what you think