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

truncate/1 incorrect #2772

Open
UWN opened this issue Jan 15, 2025 · 5 comments · May be fixed by #2777
Open

truncate/1 incorrect #2772

UWN opened this issue Jan 15, 2025 · 5 comments · May be fixed by #2777

Comments

@UWN
Copy link

UWN commented Jan 15, 2025

?- X is truncate(1.0e300).
   X = 9223372036854775807, unexpected. % should be much much larger
?- X is 1.0*truncate(1.0e300).
   X = 9.223372036854776e18, unexpected.
   X = 1.0e300. % expected, but not found
@UWN
Copy link
Author

UWN commented Jan 15, 2025

In fact,

?- between(1,400,N),F is 10**N,V is truncate(F), V = 9223372036854775807.
   N = 19, F = 1.0e19, V = 9223372036854775807, unexpected
;  ...
;  N = 308, F = 1.0e308, V = 9223372036854775807, unexpected
;  error(evaluation_error(float_overflow),(**)/2).
   evaluation_error(float_overflow). % expected, but not found directly

@UWN
Copy link
Author

UWN commented Jan 15, 2025

?- 0x7fffffffffffffff = 9223372036854775807.
   true.

@triska
Copy link
Contributor

triska commented Jan 17, 2025

From a preliminary glance, I found:

self.machine_st.interms[t - 1] = truncate(n1, &mut self.machine_st.arena);

But the function that may yield a more correct result (if rounded) seems to be trunc (not truncate) (dubious!). @bakaq, @adri326, I would greatly appreciate your input and help with this, thank you a lot!

@adri326
Copy link
Contributor

adri326 commented Jan 17, 2025

Oh this is the place I couldn't find again while working on this part of the codebase. rnd_i casts f (an f64) into an i64 and then into an Integer. The fix would be to use Integer::try_from(f) instead

@adri326
Copy link
Contributor

adri326 commented Jan 17, 2025

Yup, that does the trick :)

adri326 added a commit to adri326/scryer-prolog that referenced this issue Jan 17, 2025
Fixes mthom#2772.

The current implementation of `rnd_i` incorrectly casts `f` (an `f64`)
into an `i64`, before casting it into an `Integer`.

This fixes that issue by using `Integer::try_from(f)` instead.
@adri326 adri326 linked a pull request Jan 17, 2025 that will close this issue
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 a pull request may close this issue.

3 participants