Wrong math for big integers

[baterflyrity]

Describe the bug
This issue is extracted from #2939 (comment) to avoid spam and clarify comments.

Basically, arithmetic just wrong.

To Reproduce

$ echo 13911860366432393 | jq ".-10"
13911860366432380

Expected behavior

Should be 13911860366432383 or at least 13911860366432382.

Environment (please complete the following information):

• OS and Version: Windows 10 x64
• jq version: jq-1.7-dirty

Additional context

Please, read preceding comment corresponding to this issue in original thread.

[wader]

Hi, is this jq 1.7 or jq master? after #2949 was merged jq will still truncate but it will truncate more similar to what the JSON spec suggests (double/binary64) and what other language implementations like ex node do. Currently jq only promises to preserve big integers if no operation is done with them.

$ echo 13911860366432393 | ./jq ".-10"
13911860366432382

$ node -p '13911860366432393-10'
13911860366432382

[itchyny]

Arithmetic operations convert numbers to double precision, as described in https://jqlang.github.io/jq/manual/#identity.

[baterflyrity]

Arithmetic operations convert numbers to double precision, as described in https://jqlang.github.io/jq/manual/#identity.

Please, read the text in this thread at first:

Windows, jq-1.7-dirty:

$ echo 13911860366432393 | jq ".-10"
13911860366432380

Linux, jq-1.6:

$ echo 13911860366432393 | jq ".-10"
13911860366432382

Hi, is this jq 1.7 or jq master?

This is the latest choco jq available. Hope, your patch will fix it in next windows release.

[itchyny]

We can't expect 13911860366432393 to be expressed exactly in double precision, because it is larger than the maximum integer 2^53 = 9007199254740992, the numbers under which are exactly representable in double precision floating numbers. Between 2^53 and 2^54, even numbers are representable exactly, and your number is in this range, so 13911860366432393 is likely rounded to 13911860366432392, thus .-10 should be 13911860366432382, as @wader showed by node command.

[baterflyrity]

We can't expect 13911860366432393 to be expressed exactly in double precision, because it is larger than the maximum integer 2^53 = 9007199254740992, the numbers under which are exactly representable in double precision floating numbers. Between 2^53 and 2^54, even numbers are representable exactly, and your number is in this range, so 13911860366432393 is likely rounded to 13911860366432392, thus .-10 should be 13911860366432382, as @wader showed by node command.

Thanks for detailed explanation, but jq gives 13911860366432380 instead of 13911860366432382.

[wader]

Thanks for detailed explanation, but jq gives 13911860366432380 instead of 13911860366432382.

That is with 1.7? there was a regression that now has been fixed in jq master so in the next release things will work as in 1.6 again.

If you want a jq implementation with big integers support maybe you can try https://github.com/itchyny/gojq?

I wonder if @leonid-s-usov ever planned to support doing operations with decnum?

[leonid-s-usov]

My first implementation did that, and really, it's a trivial change to submit. However, at the time of writing the feature, it was considered dangerous to alter the default behavior, due to both compatibility and performance concerns.

Maybe we could consider a separate command line switch to enable the (almost) arbitrary precision decimal math.

[wader]

My first implementation did that, and really, it's a trivial change to submit. However, at the time of writing the feature, it was considered dangerous to alter the default behavior, due to both compatibility and performance concerns.

I suspect that :) but now after the regression in 1.7 and not that many ppl seems to have noticed maybe at least compatibility is not much of concern? :)

Maybe we could consider a separate command line switch to enable the (almost) arbitrary precision decimal math.

Yeap that would probably be a good idea as a first step.

[leonid-s-usov]

To clarify, decimal math would only be used for primitive operations, such as + - * / % <=>. TBH, I would reconsider and maybe allow decimal math on the mentioned operations unconditionally. Maybe we should raise this with the release team