From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inaccurate results from numeric ln(), log(), exp() and pow() |
Date: | 2015-11-14 16:13:39 |
Message-ID: | 6758.1447517619@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> I'm much less happy with the sqrt() range reduction step though. I now
> realise that the whole increment local_rscale before each sqrt()
> approach is totally bogus.
Yeah, I was wondering about that yesterday ...
> So repeated use of sqrt() can be used for range reduction, even in
> extreme cases, and it won't lose precision if it's done right. In
> fact, in the worst case there are only 22 sqrts() by my count.
Cool.
> We might well want to keep the power-10 argument reduction step, but
> it would now be there purely on performance grounds so there's scope
> for playing around with the threshold at which it kicks in.
My inclination is to get rid of it. I thought having ln_var recurse was
rather ugly, and I'm suspicious of whether there's really any performance
benefit. Even with the pow_10 reduction, you can have up to 7 sqrt steps
(if the first digit is 9999, or indeed anything above 445), and will
almost always have 4 or 5. So if the pow_10 reduction costs about as much
as 7 sqrt steps, the input has to exceed something like 1e170 before it
can hope to win. Admittedly there's daylight between there and 1e128000,
but I doubt it's worth carrying extra code for.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-11-14 16:34:51 | Re: pg_stat_statements query jumbling question |
Previous Message | Craig Ringer | 2015-11-14 14:45:17 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |