Re: float output precision questions - Mailing list pgsql-hackers

On Wed, 30 Oct 2002, Pedro Miguel Frazao Fernandes Ferreira wrote:

> In C this is possible:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
>    double v;
>    char a[30];
>
>    v=1.79769313486231571e+308;
>
>    printf("           Stored double number: %25.18g\n",v);
>    sprintf(a,"%25.18g",v);
>    printf("            Converted to string: %s\n",a);
>    v=atof(a);
>    printf("Converted from string to double: %25.18g\n",v);
> }

AFAICT, this is not guaranteed to give you the same representation that
you're using in the initializer however.

> Using standard PostgreSQL query output it would not be possible to get
> this number, which has representation as a double.

> I fetched the PostgreSQL source from Debian, changed
> src/backend/utils/adt/float.c to do sprintf(ascii, "%25.18g", num)
> instead of sprintf(ascii, "%.*g", DBL_DIG, num), compiled and installed.
> Now I can get the number as is.
>
> I understand that if people insert a value of 1.1 in a double, they want
> to get 1.1 without knowing that in fact the stored number is
> 1.10000000000000009. But do you understand that if some people insert,
> for example, a value of 1.79769313486231571e+308 they dont want to get
> 1.79769313486232e+308 which does not compare equal (in Matlab or C) to
> the first ? This is a bug.

I disagree to some extent.  I'm not sure it's meaningful to expect that
(what if the database and the client are on different architectures) in
general.  In any case, you're effectively going from decimal
representation to double to decimal representation (the string you used
to insert it -> internal representation -> string used to output it) and
that's only guaranteed to be correct up to DBL_DIG digits as far as I can
tell.  I think it'd be nice to have an option to get more digits for those
sorts of applications, however.

> > This would probably make sense as an option, so why don't you look at the
> > past discussions and see if you can come up with a solution that keeps
> > everyone happy (and preferably implement it, but...) :)
>
> but ???

, but I realize that you might not be interested in doing such. (I figured
the last part was implied)

> I have a sugestion:
>
> To have parameters, say DOUBLE_FORMAT and FLOAT_FORMAT, which could have
>   option values of 'SHORT' and 'LONG'.
> Option 'SHORT' would be default and produce the standard sprintf(ascii,...
> Option 'LONG' would produce sprintf(ascii, "%25.18g", num).
>
> Other way would be to have number parameters to be used in the sprintf
> calls, in place of 25 and 18, in the format string.

From what Tom said, something similar was suggested and there were issues
brought up.  I don't know what they were, since I wasn't personally
terribly interested, but it should be in the archives.  If there were any
concerns, you'll probably need to deal with those as well.