Conversation
doriable
reviewed
Apr 7, 2026
| } else { | ||
| meta.Word = math.Float64bits(f64) | ||
| l.scratchFloat.SetUint64(0) | ||
| fmt.Println(digits) |
Member
There was a problem hiding this comment.
nit: ^^" leftover debug message, maybe?
| l.scratchFloat.SetUint64(0) | ||
| case v.IsFloat(): | ||
| f, acc := v.Float().Float64() | ||
| fmt.Println(digits, f) |
| braces []token.ID | ||
| scratch []byte | ||
| scratchFloat *big.Float | ||
| scratchInt big.Int |
Member
There was a problem hiding this comment.
Nit: ... should we also store the pointer here?
| return z | ||
| } | ||
|
|
||
| // IsInt returns whether this value is representable as a base 2 float. |
| return f | ||
| } | ||
|
|
||
| // SetInt sets this decimal's value to x. |
Comment on lines
+84
to
+85
| prec = 6 | ||
| havePrec = true |
Member
There was a problem hiding this comment.
Nit: Is it worth having a comment that this corresponds to the defaults in fmt? Or is this a universal kind of default?
| {in: "1.2.3", invalid: true}, | ||
| // Invalid: exponent with no digits. | ||
| {in: "1e", invalid: true}, | ||
| } |
Member
There was a problem hiding this comment.
Should we have an invalid test case for 0x0.fe+4 (e.g. mixing bases in scientific notation)?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds a new decimal (aka base-10 floats) to the compiler, which very carefully parses all of the formats we care about while retaining exact precision.
This fixes what was essentially a workaround for using
big.Float, which cannot exactly represent most floating-point literals. For example,0.1has no exact representation. Previously, I implemented a hacky workaround which handled most cases where we only cared aboutfloat64(53 bits) of precision, but not always. Instead of layering on more hacks, I implemented this abstraction.The new type does not currently support arithmetic, although we will eventually need to implement it. Decimal arithmetic is very painful. I have already spent a week chasing bugs in this PR and do not want to spend even more time on fussy multi-base arithmetic.
Also worth noting that a few tests have changed, because we are able to get more precise results. In particular, this fixes a conformance error where
1e-10in one of our tests would lose more precision than if we usedfloat64as the internal representation.