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 ?
Luc
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
