[vim/vim] WIP: Conditionally support `long double` type for `float_T` (PR #15902)
S0AndS0
⚠️ This breaks echo and messes with other Vim Ex mode commands, ex;
echo json_encode({'value':0.5670403838157654})
Results could be;
{"value":5.068898e-310}{"value":1.237282e-313}{"value":0.0}
:echo json_decode('{"value":0.5670403838157654}')
Results, regardless of float size, always be;
{'value': 0.0}
... Side note; printf within Vim Ex mode also has inconsistent behaviors.
Questions
- Is this worth pursuing? And if so;
- What causes the inconsistencies?
- Where else do I need to apply updates?
- Is there a convenient way to avoid/expand
enotation? - Any pointers on adding some unit tests?
Story time
I'm writing a plugin, aimed at Vim8 compatibility, that makes calls to an API that I do not control outputs of. And the API returns JSON that contains large floats, example;
{
"embedding": [
0.5670403838157654,
0.009260174818336964,
0.23178744316101074,
-0.2916173040866852,
-0.8924556970596313,
0.8785552978515625,
-0.34576427936553955,
0.5742510557174683,
-0.04222835972905159,
-0.137906014919281
]
}... As of Vim version 9.1.1-785 packaged by Arch, I use Arch (BTW™), these values are truncated to about five digits past the decimal point, eg.
:echo json_decode('{"embedding":[0.5670403838157654]}')
Result:
{'embedding': [0.56704]}
Oddly it looks like this might be a echo bug, because wrapping with printf and using a large limit mostly preserves precision of input floats... mostly
:echo printf('%.25g', json_decode('{"embedding":[0.5670403838157654]}').embedding[0])
Result:
0.5670403838157653808593750Notice, we lost the last
4and picked-up a bunch of extra3808593750🤷
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/15902
Commit Summary
- 635f545 Start supporting more precision with floats
File Changes
(1 file)
- M src/structs.h (11)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Tony Mechelynck
I can't find it back in the Vim help, but IIRC :echo has always displayed Floats with some standardized default precision of 6 significant digits or so regardless of what the hardware could handle. With printf(), OTOH, it is possible to specify the precision, including a better precision than what the hardware affords, in which case "anything" will be displayed beyond the hardware limit. For instance if you try to use printf() to display 1.0 / 3.0 with tremendous precision, you'll notice that at some point it ceases to be a string of repetitions of the digit 3.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
It currently is at :h floating-point-precision
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Tony Mechelynck
It currently is at
:h floating-point-precision
Ah, thanks. Yes, this is what I meant.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Isn't that just a display issue only? In which case I think we don't even need to worry about?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
S0AndS0
I agree that echo be a non-issue to worry about, and the main thing I'm currently concerned with is preserving precision whenever possible; especially in regards to JSON encode/decode operations.
Double-checking myself on Vim version 9.1.1-785, after learning that echo for sure cannot be trusted, it looks like the decoding is fine, ex.
let json_stringy = '{ "value": "0.009260174818336964" }' let json_floater = '{ "value": 0.009260174818336964 }' let parsed_stringy = printf('%s', json_decode(json_stringy).value) let parsed_floater = printf('%.18g', json_decode(json_floater).value) echo parsed_stringy == parsed_floater "> 1 echo len(parsed_stringy) "> 20 echo len(parsed_floater) "> 20
... But things get funky when re-encoding;
echo json_encode(json_decode(json_stringy)) "> {"value":"0.009260174818336964"} echo json_encode(json_decode(json_floater)) "> {"value":0.00926}
So I may need to revert previously proposed changes and instead fixate on what json_encode is doing to floats.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
S0AndS0
@S0AndS0 pushed 5 commits.
- 08ef56b runtime(doc): improve the :colorscheme documentation
- c967728 patch 9.1.0794: tests: tests may fail on Windows environment
- 15c8286 Define a precision for floats
- 0d6b7c1 Add `long double` AKA _long float_ type
- 6caf1f3 :warning: Start using _long float_ type
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
S0AndS0
I think I got most of the bits for allowing long double (AKA long floats) usage!
Only bit that is being a stinker are print/echo-ing dictionaries as a whole, eg.
echo {'floater': 0.419} "> `{'floater': 0.00000000000000000000}` echo {'floater': 0.419}.floater "> `6.95323265041282803632e-310`
... But if feels close to doable, closer at least, and it seems printf is now properly passing the long variants of floats;
echo printf('%.18Lg', {'value':0.00926017481833696365}.value) "> `0.009260174818336964`
TLDR I'd much appreciate a pointer to where I'm messing thing up when a dictionary''
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
S0AndS0
Please do not change version.c in a PR
Uh-oh 🤦 ... I'll try to get that reverted soon
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
Please do not change version.c in a PR
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
S0AndS0
@S0AndS0 pushed 0 commits.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#15902)this has stalled, so closing
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.