Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tweak Gain arithmetic #463

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Tweak Gain arithmetic #463

wants to merge 3 commits into from

Commits on Jul 10, 2021

  1. Provide unary +/- for Level/Gain

    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
    Keno committed Jul 10, 2021
    Configuration menu
    Copy the full SHA
    380dfd5 View commit details
    Browse the repository at this point in the history
  2. Tweak Gain arithmetic

    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.
    Keno committed Jul 10, 2021
    Configuration menu
    Copy the full SHA
    09d7ca0 View commit details
    Browse the repository at this point in the history

Commits on Jul 16, 2021

  1. Apply suggestions from code review

    Co-authored-by: Sebastian Stock <[email protected]>
    giordano and sostock authored Jul 16, 2021
    Configuration menu
    Copy the full SHA
    1d4f91b View commit details
    Browse the repository at this point in the history