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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
