Re: Function trunc() behaves in unexpected manner with different data types
От | Greg Stark |
---|---|
Тема | Re: Function trunc() behaves in unexpected manner with different data types |
Дата | |
Msg-id | AANLkTin81WeP3+gOjyp6bX-m26vUjcBRBd2GRGkWwMxZ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Function trunc() behaves in unexpected manner with different data types (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: Function trunc() behaves in unexpected manner with different data types
|
Список | pgsql-bugs |
On Thu, Feb 24, 2011 at 7:31 PM, Merlin Moncure <mmoncure@gmail.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 по дате отправления: