raghav-reglobe opened a new issue, #69218:
URL: https://github.com/apache/doris/issues/69218
**Search before asking:** yes.
**Version:** master (V2 variant ingestion).
**What's wrong**
`format_json_double` in be/src/exprs/function/parse/variant_string_parse.cpp
formats a double with
`std::numeric_limits<double>::digits10 + 1` = 16 significant digits. A
binary64 can need 17 (`max_digits10`), so two
different doubles render as the same text and a reader that parses the text
back gets the neighbour:
```sql
SELECT CAST(v AS STRING) AS document_text, CAST(v['s'] AS STRING) AS
element_text
FROM (SELECT
parse_to_variant('{"s":0.30000000000000004,"q":1997.6000000000001}') AS v) t;
-- master: {"q":1997.6,"s":0.3}
0.30000000000000004
-- fixed: {"q":1997.6000000000001,"s":0.30000000000000004}
0.30000000000000004
```
The stored value is the source binary64 (the element path is exact); the
loss is in the rendering. Any pipeline that
serialises a VARIANT to text and parses a number out of it (`json_extract_*`
over `CAST(v AS STRING)`, exports, re-loads)
silently moves roughly one in five doubles to the adjacent value.
**What you expected**
The document text renders every double in a form that parses back to the
same double, as the element path already does.
**Fix**
Use fmt's default `{}` formatting (Dragonbox, the shortest representation
that round-trips) instead of `{:.16g}`.
Test: seven doubles through both text surfaces and one document
(0.30000000000000004, 1997.6000000000001, 1997.6, 0.1,
1e16, 123456789012345680, -2.5e-7). PR follows.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
