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: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 <> 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)).

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
>> 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:
>>> 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