Re: Ryu floating point output patch
Donald Dong <xdong@csumb.edu>
From: Donald Dong <xdong@csumb.edu>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Andres Freund <andres@anarazel.de>,
Tom Lane <tgl@sss.pgh.pa.us>,
Robert Haas <robertmhaas@gmail.com>,
Chapman Flack <chap@anastigmatix.net>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-01-17T05:10:33Z
Lists: pgsql-hackers
Attachments
- test_float4.patch (application/octet-stream) patch
> On Jan 15, 2019, at 2:37 AM, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote: > > Andres> strtod()'s job ought to computationally be significantly easier > Andres> than the other way round, no? And if there's buggy strtod() > Andres> implementations out there, why would they be guaranteed to do > Andres> the correct thing with our current output, but not with ryu's? > > Funny thing: I've been devoting considerable effort to testing this, and > the one failure mode I've found is very interesting; it's not a problem > with strtod(), in fact it's a bug in our float4in caused by _misuse_ of > strtod(). Hi, I'm trying to reproduce the results by calling float4in in my test code. But I have some difficulties linking the code: testfloat4.c:(.text+0x34): undefined reference to `float4in' testfloat4.c:(.text+0x3c): undefined reference to `DirectFunctionCall1Coll' I tried offering float.o to the linker in addition to my test program. I also tried to link all the objects (*.o). But the errors still exist. I attached my changes as a patch. I wonder if creating separated test programs is a good way of testing the code, and I'm interested in learning what I missed. Thank you.
Commits
-
Provide an extra-float-digits setting for pg_dump / pg_dumpall
- af25bc03e17e 12.0 landed
-
Change floating-point output format for improved performance.
- 02ddd499322a 12.0 landed
-
Use strtof() and not strtod() for float4 input.
- f397e08599a3 12.0 landed