-
Notifications
You must be signed in to change notification settings - Fork 988
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
Numbers with small mantissa widths #866
Comments
From https://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.8:
Chez Scheme uses the precision of IEEE double-precision floating-point numbers. According to https://scheme.com/tspl4/objects.html#./objects:s76,
|
This is consistent with what I reported. The binary floating-point number denoted by The issue is relevant for accurate writing and reading of inexact numbers (which has a great tradition in Scheme 😉) across Schemes with varying precisions. A Scheme with a mantissa width of one could write |
It looks as though s/strnum.ss discards the p of "x | p" on input, which is allowed by R6RS since it uses the largest available precision, that of the IEEE double float. Regarding exchanging floating-point numbers between systems, I'd strongly recommend using a binary protocol like Google's protobuf. I've been burned many times when using base-10 representations. Accurately printing and reading floating-point numbers is difficult, and I've encountered many libraries that don't get all the details correct. |
If you'd like to implement what you're proposing, you can find the code that converts exact numbers to floating-point in S_floatify of c/number.c. |
I am more concerned about the correctness of Chez Scheme with respect to R6RS. If a Scheme implementation were allowed to simply drop the mantissa width on reading, it would be mostly meaningless. I am going to try to reach the authors of SRFI 77, which became part of R6RS.
Thank you for pointing this out to me. It seems to me that lines like Line 206 in 74ca188
inexact , so that the code in c/number.c won't have to be touched.
|
Here is the thread I opened on the SRFI 77 mailing list: https://srfi-email.schemers.org/srfi-77/threads/2024/08/ Independently, it occurred to me that we can simplify the discussion about the meaning of I expect
but I get
|
What would your proposal return for |
The same as for
|
But |
Yes. When there is no explicit mantissa width, nothing changes compared to the current behaviour of Chez Scheme. (Virtually all code does not use explicit mantissa widths, so this is an important point.) This is consistent with R6RS, which demands:
Chez Scheme already computes inexact real number objects using a mantissa width of 53 (barring subnormal numbers); exact numbers are subject to some default mantissa width. |
So you're proposing that the vertical bar has higher precedence than the |
Yes, it does. Let me quote the third paragraph of section 4.2.8. of R6RS:
It follows from that paragraph that |
Page 16 of the R6RS says that
x|p
represents the best binary floating-point approximation ofx
using ap
-bit significand. Chez Scheme does not seem to comply with it. For example, at the REPL:The denominator is the value of
(expt 2 55)
. However, the best floating-point approximation of0.1
with a mantissa width of 1 bit has a very small power of two in the denominator.The text was updated successfully, but these errors were encountered: