commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
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 <> 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
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)).


> Another limitation is that your function cannot store intermediate results as clas attributes
> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message