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 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 "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? Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
