Re: float output precision questions - Mailing list 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@postgresql.org)
> 
> 


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