Phil Steitz <phil.ste...@gmail.com> a écrit :
>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?
Yes. The current archictecture was designed to allow transforming several
methods with different names and signatures.
I thought this would in fact be simpler than managing fields. The only problem
I anticipated is that we must track things
like the top level function f(t) calling g(constant1, t) at one instruction,
calling g(t, constant2) at another instruction and g(t, t)
at yet another instruction. We should probably manage a stack for methods
pending transformation and keep a reference to
the call sequences so we can decide which signature we need (either with only a
double and a differential pair or a differential pair
and a double, or two differential pairs). Once we have chosen the transformed
signature, we can insert the transformed calling
sequence. This also imply we should be able to change a method even if it
appears in the class before the method that calls it. This
is possible thanks to the tree API.
Luc
>
>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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
