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

eval: loss of Precision in Arithmetic Operations on 35-Digit Integers #3787

Open
takonomura opened this issue Feb 27, 2025 · 2 comments
Open

Comments

@takonomura
Copy link

What version of CUE are you using (cue version)?

$ cue version
cue version v0.12.0

go version go1.23.5
      -buildmode exe
       -compiler gc
       -trimpath true
  DefaultGODEBUG asynctimerchan=1,gotypesalias=0,httpservecontentkeepheaders=1,tls3des=1,tlskyber=0,x509keypairleaf=0,x509negativeserial=1
     CGO_ENABLED 1
          GOARCH arm64
            GOOS darwin
         GOARM64 v8.0
cue.lang.version v0.12.0

Does this issue reproduce with the latest stable release?

Yes

What did you do?

exec cue eval
cmp stdout stdout.golden

-- x.cue --
package x

a: 10000000000000000000000000000000001
b: 10000000000000000000000000000000000 + 1
c: 10000000000000000000000000000000002 - 1

// 34-digit integer works
x: 9999999999999999999999999999999998
y: 9999999999999999999999999999999997 + 1
z: 9999999999999999999999999999999999 - 1
-- stdout.golden --
a: 10000000000000000000000000000000001
b: 10000000000000000000000000000000001
c: 10000000000000000000000000000000001
x: 9999999999999999999999999999999998
y: 9999999999999999999999999999999998
z: 9999999999999999999999999999999998

What did you expect to see?

I expected the test to pass.
According to https://cuelang.org/docs/reference/spec/#numeric-values, I expected arithmetic operations on integer values to be performed with at least 256-bit precision.

What did you see instead?

$ testscript test.txtar
> exec cue eval
[stdout]
a: 10000000000000000000000000000000001
b: 1.000000000000000000000000000000000e+34
c: 1.000000000000000000000000000000000e+34
x: 9999999999999999999999999999999998
y: 9999999999999999999999999999999998
z: 9999999999999999999999999999999998
> cmp stdout stdout.golden
diff stdout stdout.golden
--- stdout
+++ stdout.golden
@@ -1,6 +1,6 @@
 a: 10000000000000000000000000000000001
-b: 1.000000000000000000000000000000000e+34
-c: 1.000000000000000000000000000000000e+34
+b: 10000000000000000000000000000000001
+c: 10000000000000000000000000000000001
 x: 9999999999999999999999999999999998
 y: 9999999999999999999999999999999998
 z: 9999999999999999999999999999999998

FAIL: test.txtar:2: stdout and stdout.golden differ
failed run
@takonomura takonomura added NeedsInvestigation Triage Requires triage/attention labels Feb 27, 2025
@myitcv myitcv changed the title Loss of Precision in Arithmetic Operations on 35-Digit Integers eval: loss of Precision in Arithmetic Operations on 35-Digit Integers Feb 27, 2025
@myitcv
Copy link
Member

myitcv commented Feb 27, 2025

Thanks for the report @takonomura. Please can you provide some context in which you are running into this? For example, is this a financial application?

I will let @mpvl reply here in the first instance regarding CUE's choice to drop down to float here.

But for now just link #1883. And further note that at least I have wondered if there is a place for a mode of CUE which use math/big or similar for all computations, with an acceptance in such a mode that performance will be impacted.

@myitcv myitcv removed the Triage Requires triage/attention label Feb 27, 2025
@takonomura
Copy link
Author

Please can you provide some context in which you are running into this?

I am trying to perform arithmetic operations on IP addresses by adapting the method described at #3142 (comment). The approach works well for IPv4 addresses (32-bit, 10 digits), but I encountered an issue when applying the same method to IPv6 addresses (128-bit, 39 digits).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants