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 developersoriented 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
> halfderivatives, 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 javadefined 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, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
