On 10/29/11 10:24 PM, Phil Steitz wrote: > 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)).
Sorry, I keep forgetting here that we are working with bytecode, so in theory you could chase down the source classes, making c) possible. Is that what you had in mind? Phil > > 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
