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

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

Open
chiphogg opened this issue Dec 12, 2022 · 0 comments
Open

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

chiphogg opened this issue Dec 12, 2022 · 0 comments
Labels
⬇️ affects: code (interfaces) Affects the way end users will interact with the library 📁 kind: enhancement New feature or request 💪 effort: epic Major features that will take considerable planning and effort to add

Comments

@chiphogg
Copy link
Contributor

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".

@chiphogg chiphogg added the 📁 kind: enhancement New feature or request label Dec 12, 2022
@chiphogg chiphogg added the 💪 effort: epic Major features that will take considerable planning and effort to add label Jan 17, 2023
@chiphogg chiphogg added the ⬇️ affects: code (interfaces) Affects the way end users will interact with the library label Mar 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⬇️ affects: code (interfaces) Affects the way end users will interact with the library 📁 kind: enhancement New feature or request 💪 effort: epic Major features that will take considerable planning and effort to add
Projects
None yet
Development

No branches or pull requests

1 participant