Skip site navigation (1) Skip section navigation (2)

need higher extra_float_digits value (3)

From: Keh-Cheng Chu <kehcheng(at)sun(dot)Stanford(dot)EDU>
To: pgsql-bugs(at)postgresql(dot)org
Cc: Keh-Cheng Chu <kehcheng(at)sun(dot)Stanford(dot)EDU>
Subject: need higher extra_float_digits value (3)
Date: 2009-09-09 18:51:52
Message-ID: 20090909185152.GA7893@kehcheng.Stanford.EDU (view raw or flat)
Thread:
Lists: pgsql-bugs
I have applications that require IEEE floating-point data
to remain unchanged to the last bit after a dump/restore
cycle.  Currently on all our linux systems, pg_dump uses 
8 significant figures (FLT_DIG + 2) to dump 32-bit reals 
and 17 significant figures (DBL_DIG + 2) to dump 64-bit 
doubles, where FLT_DIG and DBL_DIG are defined in float.h 
as 6 and 15, respectively, and 2 is the maximum allowed value 
for extra_float_digits.  

While 17 decimal digits are sufficient to guarantee the 
complete recovery of all 64-bit double values, some 32-bit 
reals actually require NINE significant figures.  For example, 
the binary real 0x3dcccd70 is converted using 8 significant 
figures to 0.10000122, which if converted back to binary will 
become 0x3dcccd71.  A general proof for why 9 significant 
figures are required for 32-bit reals (and 17 for 64-bit 
doubles) is in Theorem 15 of David Goldberg's "What Every 
Computer Scientist Should Know About Floating-Point Arithmetic",
which is available on the web and as an appendix to Sun's 
Numerical Computation Guide.

I have been running a locally modified postgresql server with
extra_float_digits' upper limit increased by one to 3 and a 
modified pg_dump which sets extra_float_digits to 3; I have
verified that the modification does what I need and it does 
not seem to have any side effect other than providing one 
more significant figure than needed for double precision 
binary to decimal conversion.  I would like to ask the
postgresql development team to consider it for a future
release.

Thanks,

Keh-Cheng Chu
Solar Physics Group, Hansen Experimental Physics Lab
Stanford University

  
P.S. I run slony with extra_float_digits set to 3 in 
(my locally modified) postgresql.conf in order to
get around the same precision problem.  It would be 
nice if slony would do something similar to pg_dump 
and enable the extra digits by default; I will bring 
that up with slony developers if this modification is 
accepted.

Responses

pgsql-bugs by date

Next:From: Heikki LinnakangasDate: 2009-09-09 18:58:47
Subject: Re: BUG #5038: WAL file is pending deletion in pg_xlog folder, this interferes with WAL archiving.
Previous:From: Luke KoopsDate: 2009-09-09 18:36:23
Subject: Re: BUG #5038: WAL file is pending deletion in pg_xlog folder, this interferes with WAL archiving.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group