commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: svn commit: r651074
Date Sat, 26 Apr 2008 17:07:46 GMT
Phil Steitz wrote:

> 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.

For my experience, the major use case for derivatives is as an
internal mechanism for solver like algorithms. This includes root
solvers like the Newton algorithm, optimizers like conjugate gradient,
and inversion problems (orbit determination in my case ...).

For all these cases, the derivative is computed at several places that
could be slightly moved without changing globally the application
(obviously they depend on the user-provided start point which is a
simple rough guess). Consistency overall the search interval is an
important feature. Optimizers are specially interesting as they can
handle various types of constraints, including inequality
constraints. Since the optimum for such problems is exactly on the cut
point of active constraints, it is important to be able to perform
computations at this point and that the result is consistent with the
behavior in the neighborhood of this cut point on the feasible
side. Producing a NaN at this point would prevent from computing
properly the Karush-Kuhn-Tucker conditions, throwing an
InvalidArgumentException would stop the algorithm.

This may be a biased case, but it is an important one. I don't see
real applications that need to identify the singularity.

> 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?

Yes, I think so. Perhaps we could set up a FAQ using the material from the
discussions in this thread and the previous one (the announcement for Nabla).

> 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?

JDK versions and compiler versions may change the code we start with. There is
nothing we can do against this. If we take code coming from the same source and
compiled by different compilers, we may assume all compiled versions are
functionally equivalent and may be used interchangeably, so their
differentiations are also equivalent. I don't think compilers or JDK versions
would introduce anything specific that would prevent it to run or be
differentiated elsewhere. Compilers have to comply to JVM specification.

Nabla uses asm for analysis and relies on the published JVM specification. For
sure, we will need to test it in different contexts, with different compilers
and JDK.

Luc

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


Mime
View raw message