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

Re: float output precision questions

From: "Pedro M(dot) Ferreira" <pfrazao(at)ualg(dot)pt>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: float output precision questions
Date: 2002-10-30 19:29:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Stephan Szabo wrote:
> On Wed, 30 Oct 2002, Pedro Miguel Frazao Fernandes Ferreira wrote:
>>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.

In the previous email example, in C, I was going from decimal to double 
and so on, but this is not the case when I do some simulation. In this 
case it will allways be from Matlab double to PostgreSQL float8 and from 
libpq PQgetvalue() string to Matlab double. The example was just a x86 
number example where (got the string from Matlab double) query output 
would fail.

>>>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)

ok! :)

No problem. I have seen the GUC thing in the source (guc.c etc...) and it
does not look too dificult. It has lots of examples in the code itself.
What I am saying is that I can do it if pg-people agree on the (some) 
way to do it.

>>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.

I looked at some of these emails and it seemed to me that the problem 
was that Tom did'nt want a parameter that would force people to know 
about printf number formatting. I think the first solution above (the 
SHORT and LONG way) is simple, maintains usual output as default and 
enables 'maximum' precision at request.

> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

Pedro Miguel Frazao Fernandes Ferreira
Universidade do Algarve
Faculdade de Ciencias e Tecnologia
Campus de Gambelas
8000-117 Faro
Tel./Fax:  (+351) 289 800950 / 289 819403

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2002-10-30 19:29:57
Subject: PG functions in Java: maybe use gcj?
Previous:From: Olivier PRENANTDate: 2002-10-30 19:23:46
Subject: Re: 7.3b3 ok on unixware 71[12] here

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