On 10/8/11 2:24 PM, Luc Maisonobe wrote: > > > Phil Steitz <phil.ste...@gmail.com> a écrit : > >> I am getting RTE with message above when I try to run the example >> under "updating the base and differentiated objects" in the docs. >> Is this example supposed to work with the code in trunk? Also, I am > I'll look at this tomorrow, but I think for now you need to have a standalone > function, it cannot be split > as a main function calling subfunctions. The only allowed calls are the > static methods from Math/StrictMath. > I did not add our own FastMath, but it is trivial to do.
I am not going to attempt this just yet (partly because it is not a complete solution), but to support INVOKEVIRTUAL for a simple double->double function, something like the following would work, right? I just want to make sure I understand how this is going to be possible. Say you have a function whose code is in the class being differentiated called double g(double t) that is used by f. In the source, when this is invoked you have a scalar on the stack, call this t Assume in the transformed code you are going to have t, dt coming in Run g through the differentiatior to get DifferentialPair g(Differentialpair pair) In the transformed (derivative) code for f, replace the target for the INVOKEVIRTUAL with Store t, dt aload 0 load t, dt INVOKEVIRTUAL the derivative of g What will be tricky here is handling cases where a) g has a different signature and takes other values relevant to f b) g has side effects relevant to f or c) the code for g is in another class (I think we are SOL there). I think a)-b) are solvable but tricky - the full solution for GETFIELD that takes PUTFIELD into account will help there. I think it is fair enough to say c) is out of scope. Note that c) may come into play via the signature or types involved e.g. g(new FancyType(t, foo, bar)). Phil > > Another limitation is that your function cannot store intermediate results as > clas attributes yet. > > > You can look at the junit tests for what is supported. Simple expressions, > calls to traditional functions like sin, cos, exp ..., > Simple loops and conditionals, local automatic variables should all work (I > hope ...) > >> assuming >> s/ForwardAlgorithmicDifferentiator/ForwardModeAlgorithmicDifferentiator >> throughout. Correct? > Yes, the name was changed because a distant goal will be to also support > reverse mode, which is especially > useful when computing gradients (i.e. when one scalar function depends on > many inputs and we want all partial > derivatives). > > Luc > >> Phil >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
