Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.161.171 as permitted sender)
Message-ID: <4E90C0B1.6050109@gmail.com>
Date: Sat, 08 Oct 2011 14:29:21 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: svn commit: r1179928 - in [...]
References: <20111007095927.GK17388@dusk.harfang.homelinux.org>
 <61257E46-E542-4AFE-916B-09B149B98D70@gmail.com>
 <20111007131745.GN17388@dusk.harfang.homelinux.org>
 <4E8FDC32.3000407@gmail.com>
 <20111008120547.GF17021@dusk.harfang.homelinux.org>
 <4E905C63.20306@gmail.com>
 <20111008211224.GG17021@dusk.harfang.homelinux.org>
In-Reply-To: <20111008211224.GG17021@dusk.harfang.homelinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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).

Phil  
> I'll add the additional prose.
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org