algorithm used for float -> str conversion

Hello, I just came across http://www.serpentine.com/blog/2011/06/29/here-be-dragons- advances-in-problems-you-didnt-even-know-you-had/ which talk about a paper submitted last year about a fast float -> str conversion routine. I don't know what is currently used in pypy (or in Python actually), probably the underlying libc's implementation, but this could be something interesting for people writing lots of floats in csv files. Cheers -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations Développement logiciel sur mesure : http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science

Hi, 2011/6/30 Alexandre Fayolle <alexandre.fayolle@logilab.fr>:
Someone reported the same post on the cpython tracker, and I've just filed a separate issue about this idea. http://bugs.python.org/issue12450 Note that cpython2.7 (and pypy 1.5) already uses a specific algorithm to convert float to strings: a slightly customized version of David Gay's dtoa.c: http://www.netlib.org/fp/dtoa.c it is already faster and more accurate than many libc implementations. -- Amaury Forgeot d'Arc

On Thursday 30 June 2011 10:24:00 Amaury Forgeot d'Arc wrote:
Nice! Thanks a lot for the time machinesque quick answer :-) -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations Développement logiciel sur mesure : http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science

The article says "the Grisu family acts as the default rendering algorithms in both the V8 and Mozilla Javascript engines (replacing David Gay's 17-year-old dtoa code)" I wonder if they had specific reasons to switch that could be relevant to pypy and cpython as well. For example, besides speed, Grisu implementations look way simpler than Gay's code because the latter uses arbitrary precision integers (and it has to implement them from scratch). For this reason dtoa also needs dynamic allocations, while Grisu only does simple arithmetic on machine-word integers (if my understanding is correct, from a quick look at the paper and the source of both dtoa and grisu).

Hi, 2011/6/30 Alexandre Fayolle <alexandre.fayolle@logilab.fr>:
Someone reported the same post on the cpython tracker, and I've just filed a separate issue about this idea. http://bugs.python.org/issue12450 Note that cpython2.7 (and pypy 1.5) already uses a specific algorithm to convert float to strings: a slightly customized version of David Gay's dtoa.c: http://www.netlib.org/fp/dtoa.c it is already faster and more accurate than many libc implementations. -- Amaury Forgeot d'Arc

On Thursday 30 June 2011 10:24:00 Amaury Forgeot d'Arc wrote:
Nice! Thanks a lot for the time machinesque quick answer :-) -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations Développement logiciel sur mesure : http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science

The article says "the Grisu family acts as the default rendering algorithms in both the V8 and Mozilla Javascript engines (replacing David Gay's 17-year-old dtoa code)" I wonder if they had specific reasons to switch that could be relevant to pypy and cpython as well. For example, besides speed, Grisu implementations look way simpler than Gay's code because the latter uses arbitrary precision integers (and it has to implement them from scratch). For this reason dtoa also needs dynamic allocations, while Grisu only does simple arithmetic on machine-word integers (if my understanding is correct, from a quick look at the paper and the source of both dtoa and grisu).
participants (3)
-
Alexandre Fayolle
-
Amaury Forgeot d'Arc
-
Giuseppe Ottaviano