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.200.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=XfbF2QyGtHVWg0WZZUGTdk/iJl9dCcR00MNYsBgAiUrkeBmcZxX8g+gqq/wjfwBBeSNBXyF41+UinP1FhR8LwwgGzUR2Z/BGho1MYQ8+jmN4dk7gvUUR4JN974LSoC3aHMvF1YtWbUsDtMjB0K7+h6RCk5awAt92biBmAKFSnfM=
Message-ID: <8a81b4af0804241719l760e6e40y2da4404788d1013c@mail.gmail.com>
Date: Thu, 24 Apr 2008 17:19:48 -0700
From: "Phil Steitz" <phil.steitz@gmail.com>
To: dev@commons.apache.org
Subject: Re: svn commit: r651074 - in
 /commons/sandbox/nabla/trunk/src/site/xdoc: index.xml internals.xml usage.xml
In-Reply-To: <20080423213710.794A91A9832@eris.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20080423213710.794A91A9832@eris.apache.org>

On Wed, Apr 23, 2008 at 2:37 PM,  <luc@apache.org> wrote:
> Author: luc
>  Date: Wed Apr 23 14:37:08 2008
>  New Revision: 651074
>
>  URL: http://svn.apache.org/viewvc?rev=651074&view=rev
>  Log:
>  improved documentation
>  the developers-oriented documentation has been started

Thanks, Luc!
<snip/>
>


>  +        <p>
>  +          For singularities not related to domain definition boundaries (like
>  +          <code>Math.abs</code> and conditional branches), the theoretical derivative is not
>  +          defined as a single value, but as a pair of left and a right half-derivatives, one for
>  +          each side of the singularity. Since there is little support in the IEEE754 standard
>  +          to distinguish the left and right hand side of a single value (except for zero, since
>  +          -0 and +0 both exist), we have decided to adopt a simplified approach. These cases are
>  +          implemented by simple conditional branches (we added explicitly such a conditional in the
>  +          <code>Math.abs</code> case). Nabla then simply computes the value of the smooth
>  +          derivative on the branch of the computation path that is selected at run time, depending
>  +          on the values of the input parameters. This choice allows to preserve the property of
>  +          having a derivative that is always consistent with the associated value, and it is a simple
>  +          arbitrary choice of one of the two possibilities that correspond to the mathematical result,
>  +          which by itself does not choose between them.
>  +        </p>

The problem here is that it is not an "arbitrary choice" between the
two different values - the limit that is the derivative does not
exist.  It would make more sense to me to return NaN or throw IAE in
these cases.  Is that tractable?  Moreover, is it tractable to
consistently define differentiability and throw an appopriate
exception or return NaN at points where a java-defined function is not
differentiable?

We should at least document the behavior in the javadoc in any case.

Phil

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