commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: svn commit: r651074 - in /commons/sandbox/nabla/trunk/src/site/xdoc: index.xml internals.xml usage.xml
Date Fri, 25 Apr 2008 21:21:24 GMT
Phil Steitz a écrit :
> 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?

I understand your concerns. I don't think however it would be feasible 
to detect these cases and process them specifically, be it by returning 
NaN or throwing an exception.

First, we would have to add branches to the flow of control, to add an 
equality test like this:

   if (x < 0) f(x) else g(x)
   would become
   if (x < 0) {f(x),f'(x)} else if (x == 0) {f(0),NaN} else {g(x),g'(x)}

This would really be hard. It would also not work since it would break 
for the following code, when differentiating either with respect to x or y:

   double r = Math.sqrt(x * x + y * y)
   if (x < 0) {
     return 2 * Math.atan(y / (r + x));
   else if (y < 0) {
     return -Math.PI - 2 * Math.atan(y / (r - x));
   } else {
     return Math.PI - 2 * Math.atan(y / (r - x));
   }

This code is in fact a poor man implementation of Math.atan2(y, x) for x 
and y not simultaneously null. Despite it has two different branches for 
positive and negative values of x, the function and all its derivatives 
are continuous across this test. There is a small overlap where both 
expressions yield to the same result, the branches are only here to 
avoid singularities far from x = 0 (singularities at x = +/-y).

In this case, we would introduce a special handling and a NAN or 
exception that would really be wrong. The same sort of things would 
occur for example in tabulated functions where algorithms take care to 
preserve smoothness at sampling points despite control flow branches are 
split at these points.

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

Yes, we sould document it in Javadoc but also in user documentation and 
developers documentation. I need to rewrite these sections.

Do you agree with this ?

Luc

> 
> Phil
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message