commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: svn commit: r1179928 - in [...]
Date Sat, 08 Oct 2011 23:06:28 GMT
On Sat, Oct 08, 2011 at 02:29:21PM -0700, Phil Steitz wrote:
> On 10/8/11 2:12 PM, Gilles Sadowski wrote:
> > On Sat, Oct 08, 2011 at 07:21:23AM -0700, Phil Steitz wrote:
> >> On 10/8/11 5:05 AM, Gilles Sadowski wrote:
> >>> Hi Phil.
> >>>
> >>>>  Can you live with r1180315?
> >>> [I guess that you are talking to me.]
> >>>
> >>> I still stand with the arguments of my other post about this "1e-9" constant
> >>> being confusing for the "non numerics-aware" users.
> >>> However, I can understand that we may want to also document the departure
> >>> from the math definition incurred by numerical considerations.  So, I'd
> >>> propose to add:
> >>>   "The direct assignment to 1 for values below 1e-9 is an efficiency
> >>>    optimization on the ground that the result of the full computation
> >>>    is indistinguishable from 1 due to the limited accuracy of the floating
> >>>    point representation."
> >> We are also *defining* the value to be 1 at 0.  I think the current
> >> doc is pretty clear and I do want to keep the threshold in there,
> >> since it does affect what is being returned and really amounts to
> >> part of the definition.  Adding extra prose above is OK with me, but
> >> I think its clear enough as is.
> > If you understand that "it does affect what is being returned" than it is
> > surely not clear enough as is, because, to the contrary, it does *not*
> > affect what is being returned: For any value 0 < x < 1e-9 will return 1.
> Would it actually return the same bits if we just set the value at 0
> to 1 and evaluated sin(x)/x for the rest of the values?  In that
> case, I agree, we just need to doc the value at 0.  But IIUC what is
> going on, the values returned inside the recoded interval will be
> different from what the definitional formula would (despite all
> being equal to 1 under double equals).

Answering with a few examples:
x=1.000000000000000000e-15 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=5.000000000000001000e-15 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=2.500000000000000400e-14 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=1.250000000000000200e-13 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=6.250000000000001000e-13 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=3.125000000000000500e-12 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=1.562500000000000400e-11 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=7.812500000000003000e-11 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=3.906250000000001400e-10 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=1.953125000000000700e-09 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=9.765625000000004000e-09 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=4.882812500000002000e-08 f=9.999999999999996000e-01 s=9.999999999999996000e-01
x=2.441406250000001000e-07 f=9.999999999999900000e-01 s=9.999999999999900000e-01
x=1.220703125000000700e-06 f=9.999999999997516000e-01 s=9.999999999997516000e-01
x=6.103515625000004000e-06 f=9.999999999937912000e-01 s=9.999999999937912000e-01
x=3.051757812500002000e-05 f=9.999999998447796000e-01 s=9.999999998447796000e-01
x=1.525878906250001000e-04 f=9.999999961194893000e-01 s=9.999999961194893000e-01
x=7.629394531250005000e-04 f=9.999999029872346000e-01 s=9.999999029872346000e-01
x=3.814697265625002600e-03 f=9.999975746825600000e-01 s=9.999975746825600000e-01
x=1.907348632812501400e-02 f=9.999393681227797000e-01 s=9.999393681227797000e-01

Thus: below 9.765625000000004E-9, the value of the definitional formula
(without shortcut, indicated by "f=" in the above table) is strictly the
same as the CM implementation (with shortcut, indicated by "s=" in the above
table) in that they are both the double value "1.0".

[I still don't understand what you mean by "(despite all being equal to 1
under double equals)".]

What the implementation returns is, within double precision, the result of
the mathematical definition of sinc: sin(x) / x. Hence, there is no *need*
to document any special case, not even x = 0: The fact that without the
shortcut check, we'd get NaN does not mean that the implementation departs
from the definition, but rather that it correctly simulates it (at double
[However, if we assume that the doc should integrate numerical
considerations, it doesn't hurt to add the extra prose (in which case it
becomes necessary, IMHO, to explain the "1e-9").]

Maybe I should also add a "SincTest" class where a unit test would check the
strict equality of returned values from the actual division and from the
shortcut implementation?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message