Thread: How to avoid: 9.50184e+06

How to avoid: 9.50184e+06

From
Stefan Schwarzer
Date:
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:  
  ____________________________________________________________________





Re: How to avoid: 9.50184e+06

From
"Merlin Moncure"
Date:
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

Re: How to avoid: 9.50184e+06

From
Martijn van Oosterhout
Date:
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

Re: How to avoid: 9.50184e+06

From
"Scott Marlowe"
Date:
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.

Re: How to avoid: 9.50184e+06

From
Ted Byers
Date:
--- 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