On Fri, Apr 25, 2008 at 2:21 PM, Luc Maisonobe <[EMAIL PROTECTED]> wrote: > Phil Steitz a écrit : > > > > > On Wed, Apr 23, 2008 at 2:37 PM, <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
