Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fast and accurate float to string conversion (ryu) #104

Closed
disruptek opened this issue Mar 26, 2019 · 9 comments
Closed

Fast and accurate float to string conversion (ryu) #104

disruptek opened this issue Mar 26, 2019 · 9 comments

Comments

@disruptek
Copy link

I've long been enamored with this one.

https://github.com/ulfjack/ryu

@simonkrauter
Copy link

A talk explaining Ryū: https://www.youtube.com/watch?v=kw-U6smcLzk

@awr1
Copy link

awr1 commented Apr 1, 2019

Wouldn't it be more ideal if the standard lib used ryu itself or is the possibility that that would break something too great?

@disruptek
Copy link
Author

Don't you think a first implementation should be confined to a library so everyone can A/B it against stdlib and discover bugs, pain points, or regressions? Even an impure version would be a useful starting point.

@awr1
Copy link

awr1 commented Apr 2, 2019

I mean, you're right, I was just wondering if the ultimate goal here was to upgrade the standard lib

@disruptek
Copy link
Author

I mean, you're right; the goal would be fast and accurate float conversion by default. 😄

@disruptek
Copy link
Author

I looked into this a bit and nim appears to simply sprintf under the covers. Visual C++ is getting (already has?) a Ryu implementation of std::to_chars as per https://twitter.com/StephanTLavavej/status/1031841243326754817 but AFAIK there is no such love for Clang or GCC. The right thing to do is probably to start with a wrapper and then let this eventually get implemented in the backends. The wrapper could be smart enough to use the compiler's implementation when known to exist, so that there is no penalty for code using the deprecated wrapper... Thoughts?

@Araq
Copy link
Member

Araq commented Apr 5, 2019

Thumbs up from me, a stdlib patch will be accepted.

@disruptek
Copy link
Author

IIRC, the creator mentioned that the algo for Ryu is only like 100 lines, though I looked at the source and it seemed quite a bit more extensive. If no one else wants it, I'll try to contribute; t'd be a fun first project. I'd guess that we'd want to land somewhere between the state-of-the-art C implementation and a 100 line paper implementation in terms of complexity. 😉

@timotheecour
Copy link
Member

timotheecour commented Jun 21, 2021

we now have dragonbox (refs nim-lang/Nim#18139), we should close this ( I don't have permissions to close)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants