commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [nabla] INVOKEVIRTUAL not handled yet
Date Sun, 30 Oct 2011 05:28:23 GMT
On 10/29/11 10:24 PM, Phil Steitz wrote:
> On 10/8/11 2:24 PM, Luc Maisonobe wrote:
>>
>> Phil Steitz <phil.steitz@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>


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


Mime
View raw message