Re: float output precision questions

On Wed, 30 Oct 2002, Pedro M. Ferreira wrote:

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

I was just responding to it being a bug. I don't think that expecting
a float->db->float (double->db->double) giving the same double is always
safe when you assume that the PostgreSQL machine might be on a system with
different guarantees about precision. In practice, it's probably not a
big deal.

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

Yeah, I didn't think it'd be hard, but sometimes people are unable or
unwilling to do C code for things.

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

That seems reasonable then, Tom'll probably give any other objections he
might have if he has any.