## Re: Function trunc() behaves in unexpected manner with different data types

From: Greg Stark Merlin Moncure "Nathan M(dot) Davalos" , pgsql-bugs(at)postgresql(dot)org Re: Function trunc() behaves in unexpected manner with different data types 2011-02-25 02:03:40 AANLkTin81WeP3+gOjyp6bX-m26vUjcBRBd2GRGkWwMxZ@mail.gmail.com (view raw or whole thread) 2011-02-24 19:01:21 from "Nathan M(dot) Davalos"  2011-02-24 19:31:22 from Merlin Moncure   2011-02-25 02:03:40 from Greg Stark    2011-02-25 14:46:29 from Merlin Moncure     2011-02-25 15:21:25 from Tom Lane      2011-02-25 15:28:25 from Merlin Moncure       2011-02-25 15:40:09 from Alvaro Herrera        2011-02-25 15:48:50 from Merlin Moncure         2011-02-25 16:30:08 from Merlin Moncure pgsql-bugs
```On Thu, Feb 24, 2011 at 7:31 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> the root issue I think here is that the string version of the double
> precision math is approximated:

No, it's simpler than that, all double precision math is approximated.
The root issue is that 2183.67 is not representable in a floating
point binary number. Just like 1/3 isn't representable in base 10
(decimal) numbers many fractions aren't representable in base 2
(binary) numbers. The result are repeated decimals like 0.3333... if you
multiply that by three you get 0.99999 and if you truncate that you
get 0 insted of 1.

It's the trunc() that's exposing the imprecision because like "=" it
depends on the precise value of the number down to the last digit.
Though depending on the arithmetic you can always make the precision
expand beyond the last digit anyways -- when you multiply by 100 you
magnify that imprecision too.

--
greg

```

### pgsql-bugs by date

 Next: From: Jakub Ouhrabka Date: 2011-02-25 11:20:33 Subject: Corrupted index on 9.0.3 streaming hot standby Previous: From: Tom Lane Date: 2011-02-24 23:23:47 Subject: Re: LOCALTIMESTAMP has wrong time zone