On Thu, Dec 17, 2015 at 10:38 AM, Dean Rasheed wrote:
> On 10 December 2015 at 20:02, Tom Lane wrote:
>> Robert Haas writes:
>>> It seems to be a loss of 4 digits in every case I've seen.
>>
>> I wouldn't have a problem with, say, throwing in an extra DEC_DIGITS worth
>> of rscale in each of the
On 10 December 2015 at 20:02, Tom Lane wrote:
> Robert Haas writes:
>> It seems to be a loss of 4 digits in every case I've seen.
>
> I wouldn't have a problem with, say, throwing in an extra DEC_DIGITS worth
> of rscale in each of these functions so that the discrepancies tend to
> favor more si
On 10 December 2015 at 20:02, Tom Lane wrote:
>> It seems to be a loss of 4 digits in every case I've seen.
>
> I wouldn't have a problem with, say, throwing in an extra DEC_DIGITS worth
> of rscale in each of these functions so that the discrepancies tend to
> favor more significant digits out, r
Robert Haas writes:
> On Thu, Dec 10, 2015 at 2:47 PM, Tom Lane wrote:
>> That's on me as author of the commit message, I guess. The rscale
>> in most of these functions is exactly the number of fraction digits
>> that will be emitted, and we changed the rules for computing it.
>> Not by much, i
On Thu, Dec 10, 2015 at 2:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> This patch, or something nearby, seems to have changed the number of
>> significant figures produced by log() and maybe some of the other
>> functions this patch touched.
>
> Yeah, not surprising.
>
>> It's certainly not ob
Robert Haas writes:
> This patch, or something nearby, seems to have changed the number of
> significant figures produced by log() and maybe some of the other
> functions this patch touched.
Yeah, not surprising.
> It's certainly not obvious from the commit message that this change
> was expecte
On Thu, Dec 10, 2015 at 2:25 PM, Simon Riggs wrote:
> On 10 December 2015 at 18:59, Robert Haas wrote:
>Why did we make the change? I'm not sure it's bad, but
>>
>> it seems funny to whack a user-visible behavior around like this
>> without a clearly-explained reason.
>
> Surely the title of
On 10 December 2015 at 18:59, Robert Haas wrote:
Why did we make the change? I'm not sure it's bad, but
> it seems funny to whack a user-visible behavior around like this
> without a clearly-explained reason.
>
Surely the title of the post explains?
--
Simon Riggshttp://www
On Sun, Nov 15, 2015 at 4:40 AM, Dean Rasheed wrote:
> On 14 November 2015 at 20:05, Tom Lane wrote:
>> I committed this with that change and some other
>> mostly-cosmetic revisions.
>
> Thanks.
This patch, or something nearby, seems to have changed the number of
significant figures produced by
On 14 November 2015 at 20:05, Tom Lane wrote:
> I committed this with that change and some other
> mostly-cosmetic revisions.
Thanks.
> Notable non-cosmetic changes:
>
> * I forced all the computed rscales to be at least 0, via code like
> local_rscale = Max(local_rscale, NUMERIC_MIN_D
Dean Rasheed writes:
> Yeah, that makes sense. Thinking about it some more, its potential
> benefit becomes even less apparent at higher rscales because the cost
> of ln() relative to sqrt() will become larger -- the number of Taylor
> series terms required will grow roughly in proportion to the n
On 14 November 2015 at 16:13, Tom Lane wrote:
>> 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 th
Dean Rasheed 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
On 13 November 2015 at 21:34, Dean Rasheed wrote:
> On 13 November 2015 at 18:36, Tom Lane wrote:
>> Next question: in the additional range-reduction step you added to ln_var,
>> why stop there, ie, what's the rationale for this magic number:
>>
>> if (Abs((x.weight + 1) * DEC_DIGITS) > 1
Dean Rasheed writes:
> On 14 November 2015 at 00:16, Dean Rasheed wrote:
>> I can't see a way to make that work reliably. It would need to be
>> 10^estimate_ln_weight(base) and the problem is that both exp and
>> ln_weight could be too big to fit in double variables, and become
>> HUGE_VAL, losin
On 14 November 2015 at 00:16, Dean Rasheed wrote:
> I can't see a way to make that work reliably. It would need to be
> 10^estimate_ln_weight(base) and the problem is that both exp and
> ln_weight could be too big to fit in double variables, and become
> HUGE_VAL, losing all precision.
Of course
On 13 November 2015 at 23:10, Tom Lane wrote:
> One more thing: the approach you used in power_var() of doing a whole
> separate exp * ln(base) calculation to approximate the result weight
> seems mighty expensive, even if it is done at minimal precision.
> Couldn't we get a good-enough approximat
Dean Rasheed writes:
> On 13 November 2015 at 18:36, Tom Lane wrote:
>> Seems like we arguably should do this whenever the weight isn't zero,
>> so as to minimize the number of sqrt() steps.
> It's a bit arbitrary. There is a tradeoff here -- computing ln(10) is
> more expensive than doing a sqr
On 13 November 2015 at 21:00, Tom Lane wrote:
> BTW, something I find confusing and error-prone is that this patch keeps
> on using the term "weight" to refer to numbers expressed in decimal digits
> (ie, the approximate log10 of something). Basically everywhere in the
> existing code, "weights"
On 13 November 2015 at 18:36, Tom Lane wrote:
> Next question: in the additional range-reduction step you added to ln_var,
> why stop there, ie, what's the rationale for this magic number:
>
> if (Abs((x.weight + 1) * DEC_DIGITS) > 10)
>
> Seems like we arguably should do this whenever the
BTW, something I find confusing and error-prone is that this patch keeps
on using the term "weight" to refer to numbers expressed in decimal digits
(ie, the approximate log10 of something). Basically everywhere in the
existing code, "weights" are measured in base-NBASE digits, while "scales"
are m
Dean Rasheed writes:
> On 12 November 2015 at 21:01, Tom Lane wrote:
>> I started to look at this patch, and was immediately bemused by the
>> comment in estimate_ln_weight:
> That's nonsense. The comment is perfectly correct. It's not saying the
> logarithm is negative, it's saying that the *we
On 12 November 2015 at 21:01, Tom Lane wrote:
> Dean Rasheed writes:
>> These results are based on the attached, updated patch which includes
>> a few minor improvements.
>
> I started to look at this patch, and was immediately bemused by the
> comment in estimate_ln_weight:
>
> /*
>
Dean Rasheed writes:
> These results are based on the attached, updated patch which includes
> a few minor improvements.
I started to look at this patch, and was immediately bemused by the
comment in estimate_ln_weight:
/*
* 0.9 <= var <= 1.1
*
* Its logarithm
On 16 September 2015 at 16:14, Dean Rasheed wrote:
> On 16 September 2015 at 14:49, Merlin Moncure wrote:
>>> AFAICT, this kind of slowdown only happens in cases like this where a
>>> very large number of digits are being returned.
>>
>> Can you clarify "very large"?
>>
>
> I haven't done much pe
On Wed, Sep 16, 2015 at 10:14 AM, Dean Rasheed wrote:
> On 16 September 2015 at 14:49, Merlin Moncure wrote:
>>> AFAICT, this kind of slowdown only happens in cases like this where a
>>> very large number of digits are being returned.
>>
>> Can you clarify "very large"?
>>
>
> I haven't done much
On 16 September 2015 at 14:49, Merlin Moncure wrote:
>> AFAICT, this kind of slowdown only happens in cases like this where a
>> very large number of digits are being returned.
>
> Can you clarify "very large"?
>
I haven't done much performance testing because I've been mainly
focussed on accurac
On 16 September 2015 at 09:32, Tom Lane wrote:
> Dean Rasheed writes:
> > ... For example, exp() works for inputs up to 6000. However, if you
> > compute exp(5999.999) the answer is truly huge -- probably only of
> > academic interest to anyone. With HEAD, exp(5999.999) produces a
> > number wit
Dean Rasheed writes:
> ... For example, exp() works for inputs up to 6000. However, if you
> compute exp(5999.999) the answer is truly huge -- probably only of
> academic interest to anyone. With HEAD, exp(5999.999) produces a
> number with 2609 significant digits in just 1.5ms (on my ageing
> des
On Wed, Sep 16, 2015 at 2:31 AM, Dean Rasheed wrote:
> Hi,
>
> I recently noticed that numeric log() produces inaccurate results for
> certain ranges of inputs. This isn't just small errors in the last 1
> or 2 digits, but sometimes quite large errors, with over half the
> significant digits retur
30 matches
Mail list logo
