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

Provide runtime convertibility checks #110

Open
chiphogg opened this issue Feb 18, 2023 · 2 comments
Open

Provide runtime convertibility checks #110

chiphogg opened this issue Feb 18, 2023 · 2 comments
Labels
⬇️ affects: code (interfaces) Affects the way end users will interact with the library 📁 kind: enhancement New feature or request 💪 effort: medium
Milestone

Comments

@chiphogg
Copy link
Contributor

The overflow safety surface is pretty useful, but it's also just a heuristic. It can be too restrictive in some cases, and even perhaps too permissive in a few.

In practice, unit conversions should never happen in hot loops. Thus, it would be nice if every unit conversion could be checked at runtime. These checks can be very efficient. We can generate one at compile time for every conversion. For overflow risk, we can simply compare the actual runtime value to the (compile-time constant) threshold. And for truncation error, we can perform the mod operation.

Really, the only thing stopping us is: what do we do when the check fails? Different error handling strategies are appropriate for different domains. There is no "one true error handling strategy".

Fortunately, we can separate out two steps: there's the error handling, and then there's the checking as to whether it should trigger in the first place. For the latter, we can provide functions which simply return bool. Then each project can make their own "checked conversion" function that handles errors in their preferred way.

@chiphogg chiphogg added the 📁 kind: enhancement New feature or request label Feb 18, 2023
@chiphogg chiphogg added ⬇️ affects: code (interfaces) Affects the way end users will interact with the library 💪 effort: medium labels Mar 26, 2023
@chiphogg chiphogg added this to the 0.4.0 milestone Jun 21, 2023
@chiphogg
Copy link
Contributor Author

Checklist for features before we can call this "done".

  • Quantity conversions
    • "Basic" (i.e., same-rep)
    • Explicit rep
  • QuantityPoint conversions
    • "Basic" (i.e., same-rep)
    • Explicit rep

@chiphogg
Copy link
Contributor Author

(Note to future self.)

What work remains for the explicit-rep versions? It turns out that the explicit-rep unit conversions have three steps.

  1. Static cast the value to the common type of the reps.
  2. Perform the (same-rep) unit conversion.
  3. Static cast the result to the target rep.

The existing utilities cover step 2, and steps 1 and 3 are basically the same. Thus, the main thing we need is a tool to detect when a static cast is lossy. This could be pretty tricky in general, because we need to worry about:

  • signed and unsigned integral types
  • integral to floating point (remembering that there comes a point where floating point numbers cannot represent consecutive integers)
  • floating point to integral: this is OK if the value happens to be an exact integer!

It may seem that the first step, casting to the common type, is always lossless. This isn't true, even for the integers: the common type of a signed type and some other type can be an unsigned type, which is obviously lossy. So once we make our static cast checker, we will need to call it on both entry and exit.

@chiphogg chiphogg modified the milestones: 0.4.0, 0.3.6 Jul 24, 2024
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: medium
Projects
None yet
Development

No branches or pull requests

1 participant