|From:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||emre(at)hasegeli(dot)com, a(dot)alekseev(at)postgrespro(dot)ru, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: [PATCH] Improve geometric types|
|Views:||Raw Message | Whole Thread | Download mbox|
At Mon, 2 Oct 2017 08:23:49 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+TgmoYsgw0TcjJQ1CE_6vDOxgEhxYQkfNx93Mfwx23WOLM0NA(at)mail(dot)gmail(dot)com>
> On Mon, Oct 2, 2017 at 4:23 AM, Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> > For other potential reviewers:
> > I found the origin of the function here.
> > https://www.postgresql.org/message-id/4A90BD76.firstname.lastname@example.org
> > https://www.postgresql.org/message-id/AANLkTim4cHELcGPf5w7Zd43_dQi_2RJ_b5_F_idSSbZI%40mail.gmail.com
> > And the reason for pg_hypot is seen here.
> > https://email@example.com
> > I think the replacement is now acceptable according to the discussion.
> > ======
> I think if we're going to do this it should be separated out as its
> own patch.
> Also, I think someone should explain what the reasoning
> behind the change is. Do we, for example, foresee that the built-in
> code might be faster or less likely to overflow? Because we're
> clearly taking a risk -- most trivially, that the BF will break, or
> more seriously, that some machines will have versions of this function
> that don't actually behave quite the same.
> That brings up a related point. How good is our test case coverage
> for hypot(), especially in strange corner cases, like this one
> mentioned in pg_hypot()'s comment:
> * This implementation conforms to IEEE Std 1003.1 and GLIBC, in that the
> * case of hypot(inf,nan) results in INF, and not NAN.
I'm not sure how precise we practically need them to be
identical. FWIW as a rough confirmation on my box, I compared
hypot and pg_hypot for the following arbitrary choosed pairs of
Only the first pair gave slightly not-exactly-equal results but
it seems to do no harm. hypot set underflow flag.
0: hypot=3.111269837220809e-308 (== 0.0 is 0, < DBL_MIN is 0)
pg_hypot=3.11126983722081e-308 (== 0.0 is 0, < DBL_MIN is 0)
hypot(errno:0, inval:0, div0:0, of=0, uf=1),
pg_hypot(errno:0, inval:0, div0:0, of=0, uf=0)
But not sure how the both functions behave on other platforms.
> I'm potentially willing to commit a patch that just makes the
> pg_hypot() -> hypot() change and does nothing else, if there are not
> objections to that change, but I want to be sure that we'll know right
> away if that turns out to break.
NTT Open Source Software Center
|Next Message||Nick Dro||2017-10-03 08:49:21||Postgresql gives error that role goes not exists while it exists|
|Previous Message||Andres Freund||2017-10-03 08:12:11||Re: 64-bit queryId?|