Small numbers are rounded to zero on calculation

[itchyny]

Describe the bug
In the latest version of jq, jq -n '1 / 1e-17' exits with Division by zero error, but should emit 1e+17.

To Reproduce
Run jq -n '1 / 1e-17'.

Expected behavior
Since 1e-17 is not small enough to be rounded to zero, 1e+17 is expected, just like jq 1.6.

Environment (please complete the following information):

• Both macOS, Ubuntu (on Docker).
• jq version: jq-1.6-250-gce3701f

Additional context
Likely a regression of cf4b48c.

[itchyny]

Caused by jvp_literal_number_to_double, where it reduces the number literal even if it has exponent.

[itchyny]

Another test case is 1 / 1.00000000000000000000000000001e-17. This really needs to be reduced, but should not be truncated to zero.

[nicowilliams]

I'm insufficiently familiar with decNumber. @leonid-s-usov, do you know what the fix would be here?

[itchyny]

I was thinking of using decimal64/decimal64ToString but feel some difficulties in DECNUMDIGITS. Opened #2804.

[leonid-s-usov]

I've contemplated whether to enable decnum division in the original pull request, but that seemed too big of a change since it may greatly affect the performance. For now, any math attempted on numbers will "resolve" it down to the internal floating-point representation, which is reflected in the docs:

Math
jq currently only has IEEE754 double-precision (64-bit) floating point number support.

[nicowilliams]

@leonid-s-usov this issue comes up just in conversion of literals to doubles. We don't need to consider making arithmetic operations work with decNumber yet to deal with this issue.

[leonid-s-usov]

@nicowilliams yes, correct. With @itchyny 's help we found the issue with rounding a decNumber to floating point precision and it's passing the test now