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:24:48 GMT
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)).

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