commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [nabla] INVOKEVIRTUAL not handled yet
Date Sun, 16 Oct 2011 15:01:18 GMT
Le 16/10/2011 09:24, Phil Steitz a écrit :
> On 10/9/11 7:46 AM, Phil Steitz wrote:
>> On 10/9/11 5:39 AM, Luc Maisonobe wrote:
>>> Hi Phil,
>>> Le 08/10/2011 23:42, Phil Steitz a écrit :
>>>> 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.
>>> Digging into the code, here are the bytecode operations that are
>>> not supported yet:
>>>        element access in double arrays
>>>        field access (instance fields and class fields)
>>>        method calls
>>>        array creation
>>>>>> 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.
>>>>> Another limitation is that your function cannot store
>>>>> intermediate results as clas attributes yet.
>>>> Thanks, Luc!  What I was trying to illustrate was partial
>>>> derivatives, which IIUC you need something like that example to do.
>>>> The following almost works:
>>>>      public void testPartialDerivatives() throws Exception {
>>>>           PartialFunction function = new PartialFunction(1);
>>>>           final UnivariateDerivative derivative = new
>>>> ForwardModeAlgorithmicDifferentiator().differentiate(function);
>>>>           DifferentialPair t = DifferentialPair.newVariable(1);
>>>>           Assert.assertEquals(3,
>>>> derivative.f(t).getFirstDerivative(), 0);
>>>>           Assert.assertEquals(2, derivative.f(t).getValue(), 0);
>>>>           function.setX(2);
>>>>           Assert.assertEquals(4,
>>>> derivative.f(t).getFirstDerivative(), 0);
>>>>           Assert.assertEquals(3, derivative.f(t).getValue(), 0);
>>>>       }
>>>> with
>>>> public class PartialFunction implements UnivariateDifferentiable {
>>>>       private double x;
>>>>       public PartialFunction(double x) {
>>>>           this.x = x;
>>>>       }
>>>>       public void setX(double x) {
>>>>           this.x = x;
>>>>       }
>>>>       public double getX() {
>>>>           return x;
>>>>       }
>>>>       public double f(double y) {
>>>>           return x * y + y * y;
>>>>       }
>>>> }
>>>> But I end up with java.lang.VerifyError: (class:
>>>> ExampleTest$1PartialFunction$NablaForwardModeUnivariateDerivative,
>>>> method: f signature:
>>>> (Lorg/apache/commons/nabla/core/DifferentialPair;)Lorg/apache/commons/nabla/core/DifferentialPair;)
>>>> Incompatible type for getting or setting field
>>>>       at java.lang.Class.getDeclaredConstructors0(Native Method)
>>>>       at
>>>> java.lang.Class.privateGetDeclaredConstructors(
>>>>       at java.lang.Class.getDeclaredConstructors(
>>>>       at
>>>> org.apache.commons.nabla.algorithmic.forward.ForwardModeAlgorithmicDifferentiator.differentiate(
>>>>       at ExampleTest.testPartialDerivatives(
>>> This error seems to be due to the lack of support for the GETFIELD
>>> instruction. As x is an instance field, the f method reads this
>>> field before multiplying the result.
> Right.  As an exercise to help me understand the internals of the
> code, I have been trying to figure out how to add this support.
> Working backwards from the generated bytecode, the GETFIELD and the
> ALOAD 0 before it seem to get copied unchanged:
>      ALOAD 0
>      GETFIELD PartialFunction.x : D
> Working backwards to where it should get changed,
> MethodDifferentiator#getReplacement throws RuntimeException when it
> sees a GETFIELD; but in my example it does not throw.  This means
> the instruction is not making it into the changes set.  The question
> then is a) how to modify MethodDifferentiator#identifyChanges to
> identify the need to change the instruction

Changes are deduced from a data flow analysis. We start at method entry, 
knowing that the original method signature was

   public double f(double x);

and that the transformed method signature is

   public DifferentialPair f(DifferentialPair x);

So on entry, the first (and only) parameter is changed from double to 

 From this starting point, we propagate types, using differentiation 
rules, i.e. when we see that an instruction like "add" has a 
DifferentialPair at least in one of its arguments, then its result must 
be a DifferentialPair. At the end of the data flow analysis, we have 
identified all instructions that either consume or produce 
DifferentialPair instances, these instructions must be changed as in the 
original method they did consume or produce double number instead.

> and b) how to transform
> it (and other instructions that depend on it).

Transform may depend on context. For example, if the field is only read 
in the method and never set (which is the case in this example, as the 
method computes x * y + y * y where x is the field and y is the method 
parameter), then this field should remain a simple double and the 
instruction using it should be changed from multiplication of two 
doubles (x * y) to a multiplication of a double and a DifferentialPair. 
If the field were also set (for example using setX(y * y)), then it 
would be the result of an instruction producing a DifferentialPair and 
an additional field should be set up in the generated class. We could 
either choose to set a complete "private DifferentialPair xNabla" 
containing both the value and the derivative, with some code to make 
sure the x field from the enclosing class is kept in sync, or we could 
simply use a "private double xNabla" for the derivative and still use 
the x from the enclosing class for the value, hence avoiding sync code.

> A reference to the
> enclosing class also has to be made available.  Is that already
> there somewhere?

Yes, there is a "primitive" field in the generated class that points to 
the original instance. This field is the one returned by the 
automatically generated "getPrimitive" method.

I think there is a problem in the data flow analysis, in the 
TrackingValue class. It's "merge" is never populated with anything. I 
will fix this.

I will also try to improve the debugging prints I have added a few days 
ago (creating a new class for it). It should also display the status of 
local variables and stack, as these are the main drivers for the data 
flow analysis and it is probably where the error lies here.


> Phil
>>> I have added a debug display message (to be removed later on) that
>>> should print the generated bytecode to standard error when a
>>> VerifyError exception occurs. It' clearly not targeted towards end
>>> users, but it could help during development.
>> Thanks, Luc!
>> Phil
>>> Luc
>>>>> 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 ...)
>>>> Yep, I have gotten all of this to work.  Even "knows" the chain
>>>> rule :)
>>>> Phil
>>>>>> 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:
>>> ---------------------------------------------------------------------
>>> 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