Hi all, A couple of days ago a bug has showed up regarding rounding of float here: http://www.postgresql.org/message-id/flat/20150320194337.2573.72...@wrigleys.postgresql.org#20150320194337.2573.72...@wrigleys.postgresql.org The result being that the version of rint() shipped in src/port was not IEEE compliant when rounding to even (MSVC < 2013 at least using it), leading to inconsistent results depending on if the platform uses src/port's rint() or the platform's one.
During this thread, Tom has raised as well that rounding for numeric is not that IEEE-compliant: http://www.postgresql.org/message-id/22366.1427313...@sss.pgh.pa.us For example: =# SELECT round(2.5::numeric), round(1.5::numeric), round(0.5::numeric), round(-2.5::numeric); round | round | round | round -------+-------+-------+------- 3 | 2 | 1 | -3 (1 row) =# SELECT round(2.5::float), round(1.5::float), round(0.5::float), round(-2.5::float); round | round | round | round -------+-------+-------+------- 2 | 2 | 0 | -2 (1 row) It sounds appealing to switch the default behavior to something that is more IEEE-compliant, and not only for scale == 0. Now one can argue as well that changing the default is risky for existing applications, or the other way around that other RDBMs (?) are more compliant than us for their equivalent numeric data type, and people get confused when switching to Postgres. An idea, from Dean, would be to have a new specific version for round() able to do compliant IEEE rounding to even as well... Opinions? Regards, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
