hi - i opened #255 with a fix for this, but @babakks asked to file an issue first so we have a thread to discuss. so here it is.
jq.Evaluate rounds non-integer numbers to 2 decimal places, so the output loses precision. the worst case is 0.001, it prints as 0.00 - a nonzero value ends up as zero.
repro with input {"pi": 3.14159, "small": 0.001, "big": 123456.789}, evaluating .pi, .small, .big:
.pi => 3.14
.small => 0.00
.big => 123456.79
real jq keeps full precision there (3.14159, 0.001, 123456.789).
the cause is jsonScalarToString in pkg/jq/jq.go - the non-integer branch does strconv.FormatFloat(tt, 'f', 2, 64), hardcoded to 2 decimals. the doc comment says scalars are written "similar to how jq --raw works", and jq itself doesnt round, so to me it reads like a bug and not intended behaviour.
the direction i took in #255 is precision -1 (the shortest string that round-trips the float64) for the non-integer branch, and leaving the integer branch as is so whole numbers dont grow a trailing .0. but im happy to go a different way if you'd prefer to handle it some other way. just wanted somewhere to discuss it. thanks!
hi - i opened #255 with a fix for this, but @babakks asked to file an issue first so we have a thread to discuss. so here it is.
jq.Evaluaterounds non-integer numbers to 2 decimal places, so the output loses precision. the worst case is0.001, it prints as0.00- a nonzero value ends up as zero.repro with input
{"pi": 3.14159, "small": 0.001, "big": 123456.789}, evaluating.pi,.small,.big:real jq keeps full precision there (3.14159, 0.001, 123456.789).
the cause is
jsonScalarToStringinpkg/jq/jq.go- the non-integer branch doesstrconv.FormatFloat(tt, 'f', 2, 64), hardcoded to 2 decimals. the doc comment says scalars are written "similar to how jq --raw works", and jq itself doesnt round, so to me it reads like a bug and not intended behaviour.the direction i took in #255 is precision
-1(the shortest string that round-trips the float64) for the non-integer branch, and leaving the integer branch as is so whole numbers dont grow a trailing.0. but im happy to go a different way if you'd prefer to handle it some other way. just wanted somewhere to discuss it. thanks!