Re: float output precision questions

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
Portugal
Tel./Fax: (+351) 289 800950 / 289 819403
http://w3.ualg.pt/~pfrazao