On Tue, Mar 15, 2016 at 12:02 PM, Francisco Olarte wrote:
> Hi Frank:
>
> This may byte you any day, so I wuld recommend doing
>
> s=> select v, pg_typeof(v) from (select floor(4.725 * power(cast(10 as
> numeric), 2) + 0.5)) as aux(v);
> v | pg_typeof
> -+---
> 473 | numeric
>
Hi Frank:
On Tue, Mar 15, 2016 at 6:57 AM, Frank Millman wrote:
> 2. As pointed out, there are two forms of the power function.
>
> test=> select pg_typeof(power(10, 2));
> pg_typeof
> --
> double precision
>
> test=> select pg_typeof(power(10., 2));
> pg_typeof
> --
>
> I am running PostgreSQL 9.4.4 on Fedora 22.
>
> SELECT floor(4.725 * 100 + 0.5) returns 473, which is what I expected.
>
> SELECT floor(4.725 * power(10, 2) + 0.5) returns 472, which I find surprising.
>
> Please can someone explain the anomaly.
I think I have a solution to my problem, but I
Hi,
maybe this is a late reply, but also note that 4.725 alone already cannot be
represented in floating point exactly (and this has nothing to do with
Postgres).
Just sum it up 100 times to "see" the round off error becoming visible:
chris=# select sum(4.725::double precision) from generate_s
On Mon, Mar 14, 2016 at 11:54 AM, Pujol Mathieu
wrote:
> Le 14/03/2016 15:29, Merlin Moncure a écrit :
>>
>> On Mon, Mar 14, 2016 at 9:21 AM, Pujol Mathieu
>> wrote:
>>>
>>> Hi
>>> I reproduce your bug using "PostgreSQL 9.3.6, compiled by Visual C++
>>> build
>>> 1600, 64-bit" on Windows 8
>>> I
> I am running PostgreSQL 9.4.4 on Fedora 22.
>
> SELECT floor(4.725 * 100 + 0.5) returns 473, which is what I expected.
>
> SELECT floor(4.725 * power(10, 2) + 0.5) returns 472, which I find surprising.
>
> Please can someone explain the anomaly.
Thanks for all the responses.
Plenty of workaro
On 03/14/2016 09:54 AM, Pujol Mathieu wrote:
Le 14/03/2016 15:29, Merlin Moncure a écrit :
On Mon, Mar 14, 2016 at 9:21 AM, Pujol Mathieu
wrote:
Hi
I reproduce your bug using "PostgreSQL 9.3.6, compiled by Visual C++
build
1600, 64-bit" on Windows 8
I also notice that SELECT floor(4.725 * po
Le 14/03/2016 15:29, Merlin Moncure a écrit :
On Mon, Mar 14, 2016 at 9:21 AM, Pujol Mathieu
wrote:
Hi
I reproduce your bug using "PostgreSQL 9.3.6, compiled by Visual C++ build
1600, 64-bit" on Windows 8
I also notice that SELECT floor(4.725 * power(10, 2)::numeric + 0.5) work as
expected
I
On Mon, Mar 14, 2016 at 9:29 AM, Merlin Moncure wrote:
> On Mon, Mar 14, 2016 at 9:21 AM, Pujol Mathieu
> wrote:
>> Hi
>> I reproduce your bug using "PostgreSQL 9.3.6, compiled by Visual C++ build
>> 1600, 64-bit" on Windows 8
>> I also notice that SELECT floor(4.725 * power(10, 2)::numeric + 0.5
On 03/14/2016 07:21 AM, Pujol Mathieu wrote:
Hi
I reproduce your bug using "PostgreSQL 9.3.6, compiled by Visual C++
build 1600, 64-bit" on Windows 8
I also notice that SELECT floor(4.725 * power(10, 2)::numeric + 0.5)
work as expected
Seems to be related to the two forms of power():
http://ww
On Mon, Mar 14, 2016 at 9:21 AM, Pujol Mathieu
wrote:
> Hi
> I reproduce your bug using "PostgreSQL 9.3.6, compiled by Visual C++ build
> 1600, 64-bit" on Windows 8
> I also notice that SELECT floor(4.725 * power(10, 2)::numeric + 0.5) work as
> expected
I don't think this is a bug -- just peculi
100 is an integer
power(10,2) is a double precision.
Try this one:
SELECT floor(4.725 * 100::double precision + 0.5);
On Mon, Mar 14, 2016 at 10:11 AM, Frank Millman wrote:
> Hi all
>
> I am running PostgreSQL 9.4.4 on Fedora 22.
>
> SELECT floor(4.725 * 100 + 0.5) returns 473, which is wh
Hi
I reproduce your bug using "PostgreSQL 9.3.6, compiled by Visual C++
build 1600, 64-bit" on Windows 8
I also notice that SELECT floor(4.725 * power(10, 2)::numeric + 0.5)
work as expected
Mathieu
Le 14/03/2016 15:11, Frank Millman a écrit :
Hi all
I am running PostgreSQL 9.4.4 on Fedora 2
13 matches
Mail list logo