31–40 of 45 posts
Does anyone know of a good decimal float to string converter, preferably in c?
sprintf
Does anyone know of a good decimal float to string converter, preferably in c?
Also have a look at Grisu3, Dragon4, dtoa, and the printf implementations of glibc and musl.
(De-)Serialization being such a common task both in Servers and clients nowadays I wonder if special instructions would make sense in CPUs
(not quite the same thing but heading in that direction)
Earlier quoted context omitted.
At that point just base-64 for your IEEE floats.... Because anywhere where you need that speed you can better handle it without using strings...
But that's not necessarily interoperable. E.g., some JSON parsers might produce IEEE754 doubles, but others might use arbitrary precision representations -- what then? One answer is to make JSON support only IEEE754 doubles, but it's a bit late for that, so at most one can recommend that implementors stick to IEEE754. If you are starting from scratch, and want to support only platforms that support IEEE754 in hardwar…
Does anyone know of a good decimal float to string converter, preferably in c?
C code for Ryu is available under the Apache2 and Boost licenses: https://github.com/ulfjack/ryu/tree/master/ryu Also have a look at Grisu3, Dragon4, dtoa, and the printf implementations of glibc and musl.
Ryu is somewhat faster for doubles, though SwiftDtoa has support for 80-bit and float out of the box, which is nice, and we have some further perf improvements planned. Both are considerably faster than any of the alternatives (some perf data in the original Swift PR: https://github.com/apple/swift/pull/15474), and both pass our fairly intensive test suite.
musl's implementation is also interesting for reasons of simplicity.
Earlier quoted context omitted.
But that's not necessarily interoperable. E.g., some JSON parsers might produce IEEE754 doubles, but others might use arbitrary precision representations -- what then? One answer is to make JSON support only IEEE754 doubles, but it's a bit late for that, so at most one can recommend that implementors stick to IEEE754. If you are starting from scratch, and want to support only platforms that support IEEE754 in hardwar…
You've just given me the idea that interop should be done with "hexponential" notation: 0x123ABC*0x10^0xDEF can be an exact representation of a floating point number.
The code is here: https://github.com/ulfjack/ryu
Jacob Quinn has a translation to Julia here: https://github.com/quinnj/Ryu.jl
Is Ryu.jl significantly faster than what's in Base? Is there already an open issue somewhere?
Earlier quoted context omitted.
Jacob Quinn has a translation to Julia here: https://github.com/quinnj/Ryu.jl
I really enjoy seeing Julia devs so invested and up-to-date with projects and experiments like this, because isn't this the bread and butter of technical computing? The nitty gritty of making all these bits and bytes do work! So cool. Is Ryu.jl significantly faster than what's in Base? Is there already an open issue somewhere?
I don't see an issue about it at the moment. I guess we just expect Jacob to PR it at some point. IIRC he also wrote the Grisu implementation that's in Base.