Re: [PATCH] Improve geometric types
От | Thomas Munro |
---|---|
Тема | Re: [PATCH] Improve geometric types |
Дата | |
Msg-id | CAEepm=1Dw7xZb6ZEPsVjMF4rDoW50FcR3Mk-eEUoV-hssdv9kQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Improve geometric types (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [PATCH] Improve geometric types
|
Список | pgsql-hackers |
On Sun, Jul 29, 2018 at 10:57 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Sun, Jul 29, 2018 at 10:35 PM, Tomas Vondra > <tomas.vondra@2ndquadrant.com> wrote: >> It's always 0/-0 difference, and it's limited to power machines. I'll >> try to get access to such system and see what's wrong. > > This is suspicious: > > /* on some platforms, the preceding expression tends to produce -0 */ > if (line->C == 0.0) > line->C = 0.0; I mean, it's suspiciously absent from the new line_construct() function. It was introduced here: commit 43fe90f66a0b200f6c32507428349afb45f661ca Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Fri Oct 25 15:55:15 2013 -0400 Suppress -0 in the C field of lines computed by line_construct_pts(). It's not entirely clear why some PPC machines are generating -0 here, since the underlying computation should be exactly 0 - 0. Perhaps there's some wider-than-nominal-precision calculations happening? Anyway, the best way to avoid platform-dependent results seems to be to explicitly reset -0 to regular zero. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: