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 "1e9" constant
> >>> being confusing for the "non numericsaware" 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 1e9 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 < 1e9 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.000000000000000000e15 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=5.000000000000001000e15 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=2.500000000000000400e14 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=1.250000000000000200e13 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=6.250000000000001000e13 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=3.125000000000000500e12 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=1.562500000000000400e11 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=7.812500000000003000e11 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=3.906250000000001400e10 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=1.953125000000000700e09 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=9.765625000000004000e09 f=1.000000000000000000e+00 s=1.000000000000000000e+00
x=4.882812500000002000e08 f=9.999999999999996000e01 s=9.999999999999996000e01
x=2.441406250000001000e07 f=9.999999999999900000e01 s=9.999999999999900000e01
x=1.220703125000000700e06 f=9.999999999997516000e01 s=9.999999999997516000e01
x=6.103515625000004000e06 f=9.999999999937912000e01 s=9.999999999937912000e01
x=3.051757812500002000e05 f=9.999999998447796000e01 s=9.999999998447796000e01
x=1.525878906250001000e04 f=9.999999961194893000e01 s=9.999999961194893000e01
x=7.629394531250005000e04 f=9.999999029872346000e01 s=9.999999029872346000e01
x=3.814697265625002600e03 f=9.999975746825600000e01 s=9.999975746825600000e01
x=1.907348632812501400e02 f=9.999393681227797000e01 s=9.999393681227797000e01
Thus: below 9.765625000000004E9, 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
precision).
[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 "1e9").]
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?
Gilles

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
