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

More precise types in arithmetic evaluation #1290

Merged
merged 1 commit into from
Aug 28, 2023

Conversation

oxisto
Copy link
Member

@oxisto oxisto commented Aug 24, 2023

Previously, we just casted most of our numeric types to Long when doing arithmetic operations in the ValueEvalutor. This PR tries to optimize that by introducing a number of extension functions that under the hood call the necessary Kotlin functions to properly deal with the resulting type based on the bit width.

@oxisto oxisto requested a review from KuechA as a code owner August 24, 2023 17:06
@oxisto oxisto force-pushed the more-precise-arithmetic-types-in-evaluation branch 3 times, most recently from 32715c7 to 1abe50a Compare August 25, 2023 07:13
@oxisto oxisto force-pushed the more-precise-arithmetic-types-in-evaluation branch 4 times, most recently from 7abad9d to 47ba5fd Compare August 25, 2023 18:00
Previously, we just casted most of our numeric types to `Long` when doing arithmetic operations in the `ValueEvalutor`. This PR tries to optimize that, to at least keep the type if both are the same. It is still somewhat inprecise when two different types of different bitwidth are involved. In these cases we mostly just still cast to `Long`.
@oxisto oxisto force-pushed the more-precise-arithmetic-types-in-evaluation branch from 47ba5fd to d0c4ea0 Compare August 25, 2023 18:12
@sonarcloud
Copy link

sonarcloud bot commented Aug 25, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

80.5% 80.5% Coverage
0.0% 0.0% Duplication

@KuechA
Copy link
Contributor

KuechA commented Aug 28, 2023

We may want to add a note to our gh page and say that the evaluation could return different types of numbers. This means that it might be required/useful to transfer the value e.g. via toLong() (this is related to #902 )

@oxisto oxisto merged commit a1b2ebe into main Aug 28, 2023
3 checks passed
@oxisto oxisto deleted the more-precise-arithmetic-types-in-evaluation branch August 28, 2023 09:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants