Thread: How to avoid: 9.50184e+06
Hi there,
how can I avoid results like this: 9.50184e+06
Instead it should return the "real" value, as 950184.
Thanks for any hints!
Stef
____________________________________________________________________
Lean Back and Relax - Enjoy some Nature Photography:
Appetite for Global Data? UNEP GEO Data Portal:
____________________________________________________________________
On 9/28/07, Stefan Schwarzer <stefan.schwarzer@grid.unep.ch> wrote: > Hi there, > > how can I avoid results like this: 9.50184e+06 > > Instead it should return the "real" value, as 950184. The type 'real' in postgresql comes from the mathematical definition of real, numbers that can be expressed as a fraction, or rational numbers. In a practical sense, it is an alias for the binary floating point type iirc. In your case, it looks like you should be using the integer or the numeric type. merlin
On Fri, Sep 28, 2007 at 02:08:18PM +0200, Stefan Schwarzer wrote: > how can I avoid results like this: 9.50184e+06 > > Instead it should return the "real" value, as 950184. Presumably to_text would do what you want. Alternatively, perhaps you intended your column to be type numeric? Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
On 9/28/07, Stefan Schwarzer <stefan.schwarzer@grid.unep.ch> wrote: > Hi there, > > how can I avoid results like this: 9.50184e+06 > > Instead it should return the "real" value, as 950184. > > Thanks for any hints! Cast it to numeric: select 9.50184e+06::real::numeric; But know that you're losing accuracy if you're working with real / float types. If you need all the parts of the number kept around, use numeric from the start.
--- Stefan Schwarzer <stefan.schwarzer@grid.unep.ch> wrote: > Hi there, > > how can I avoid results like this: 9.50184e+06 > > Instead it should return the "real" value, as > 950184. > But 9.50184e+06 IS the real value! That is about nine and a half million, not nine hundred and fifty thousand, BTW. I do not see why you want the database back end to divide the real number by ten and then display the result as an integer. I have not checked tbe behaviour of the functions provided by Postgresql to convert numbers to strings, but I would be surprised if a function suitable for use in serializing a floating point number failed to show 9.50184e+06 as "9.50184e+06"; to have it automagically convert it to an integer would be counter intuitive to me. Really, how a number is displayed is properly in the domain of the client application. If it is written in C, then you have functions like printf, with all their glorious format specifiers, to give you exactly what you want and expect. And you have similar control with IO streams in C++ and Java. ALL real programming languages provide support for producing formatted output, and give you absolute control over the format used. Whether you are using a thin client or a thick client, manipulating how floating point numbers really belongs in the interface layer of the client. If you want your numbers displayed as integers, then you used the wrong type (as others have also suggested). If the data really requires use of floating point numbers, then use the libraries provided by whatever language you're using to develop your client to produce the format you want. HTH Ted