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

use improved range check of 128 for float64 #157

Merged
merged 1 commit into from
Jan 28, 2022

Conversation

krux02
Copy link
Contributor

@krux02 krux02 commented Jan 16, 2022

While this fixes the original issue mentioned above, it does not fix or implement the discussions in that issue. They need to be ported to their own issue.

@krux02 krux02 force-pushed the minor-range-check-improvement branch from 6a92fd6 to 4fa7bfb Compare January 16, 2022 14:46
Copy link
Contributor

@alaviss alaviss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recall there's a test for the int128 module itself, can you add some testcases for the new function there?

And does this PR change VM behavior at all or just fixing literal construction?

compiler/int128.nim Outdated Show resolved Hide resolved
@krux02 krux02 force-pushed the minor-range-check-improvement branch from 4fa7bfb to e7684e7 Compare January 16, 2022 16:28
@saem
Copy link
Collaborator

saem commented Jan 16, 2022

I had a giant comment and I think it totally got lost. :( Oh well, it can wait.

@krux02 krux02 force-pushed the minor-range-check-improvement branch 3 times, most recently from a0dcc29 to 1236372 Compare January 19, 2022 20:11
Copy link
Contributor

@alaviss alaviss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of tweaks and this should be good to go:

  • Commit message:

    • 128 -> int128?
    • Can you mention the new saturating conversion behavior in the message body too?
  • Please add tests for the new float behaviors in tests/compiler/tint128.nim.

proc inInt128Range*(arg: float64): bool =
## Simple range check. Of coures NaN is defined not to be in range.
lowerBoundF64 <= arg and arg < upperBoundF64

proc toInt128*(arg: float64): Int128 =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest adding some docs to describe this function behavior.

Suggested change
proc toInt128*(arg: float64): Int128 =
proc toInt128*(arg: float64): Int128 =
## Return an `Int128` representing the non-factional part of `arg`.
##
## Return the maximum or minimum `Int128` when `arg` cannot be represented.

return Min
if upperBoundF64 <= arg:
return Max

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should cover NaN, too (will need an import from math):

Suggested change
if isNan(arg):
return 0

The pick of 0 is motivated by WASM and Rust.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have picked 0xDEADBEEF or something. But 0 is fine for me as well.

 * Add a range check function to test if a float64 is in rage of the int128 type.
 * Use that range check function for semexpr.checkConvertible
 * `toInt128(arg: float64)` now has clamping behavior.
 * fixes nim-works#93

While this fixes the original issue mentioned above, it does not fix or implement the discussions in that issue. They need to be ported to their own issue.
converting float64 to int128 is now clamping
@krux02 krux02 force-pushed the minor-range-check-improvement branch from 1236372 to 1cc5367 Compare January 28, 2022 19:47
@krux02
Copy link
Contributor Author

krux02 commented Jan 28, 2022

checks have passed. you can take a look again for the merge.

Copy link
Contributor

@alaviss alaviss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

bors r+

@bors
Copy link
Contributor

bors bot commented Jan 28, 2022

Build succeeded:

@bors bors bot merged commit 829ffa1 into nim-works:devel Jan 28, 2022
@krux02 krux02 deleted the minor-range-check-improvement branch January 28, 2022 21:17
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.

1e100 is considered convertible to int64 and the result is invalid
3 participants