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 ?
Luc
>
> Phil
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
