commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: svn commit: r651074 - in /commons/sandbox/nabla/trunk/src/site/xdoc: index.xml internals.xml usage.xml
Date Sat, 26 Apr 2008 00:40:07 GMT
On Fri, Apr 25, 2008 at 2:21 PM, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
> 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 ?

To be honest at this point I am not sure I understand fully the
consequences of making choices at points where functions are not
differentiable.  It could be that for practical purposes, this is not
a big deal, but it could also be that in some cases bad things could
happen because of funny behavior around cut points.  You are probably
in a better position than me to judge on this.

Documentation will be a little messy.  Seems we will have to write up
something like a recursive definition of the derived derivative
function including specification of what happens at singularities of
the JDK functions and conditionally defined functions.  Does that make
sense?

Unfortunately, even given a complete definition, users will have to
decompile functions to trace derivative computations and in theory
these could be different under different JDK versions.  Is that true?
Is it material?

Phil

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


Mime
View raw message