[ADOL-C] result seems to differ for double and adouble

Wed Aug 14 02:12:36 EDT 2013

Hello,

Thank you very much for your advices.
I hope an ADOLC expert tell me why this happens….
Is there someone familiar with the inside of ADOL-C?

Tomita

On 2013/08/13, at 5:44, Norman Goldstein <normvcr at telus.net> wrote:

> Glad to hear you've made progress.
> (btw the -g flag should also go on the link line, not just the compile line)
> 
> I don't know where to go from here.  I monitor the ADOL-C list, but I do
> not use ADOL_C (even though I think it is a great package!).  An ADOLC
> expert will be able to tell you whether the behaviour is wrong, or explain
> why it has been implemented this way.
> 
> Good luck!
> 
> 
> On 08/12/2013 05:41 AM, Nozomu Tomita wrote:
>> Hello,
>> 
>> Thank you very much.
>> I tried to do that, and I think I found where overwriting occurs.
>> 
>> By compiling this code (modified for debugging) http://pastebin.ca/2430971
>> with
>> $ g++ -g -Wall -c -O0 -I${HOME}/adolc_base/include adolc_test.cc
>> $ g++ adolc_test.o ${HOME}/adolc_base/lib64/libadolc.a 
>> and
>> $ gdb a.out
>> and to copy & paste commands http://pastebin.ca/2430973 , gdb should go the place of the problem,
>>  "adub operator * ( const badouble& x, const badouble& y )" at line 1001 in adouble.cc.
>>  (I tested in my three environment that this gdb commands works)
>> The tail of gdb output is like this: http://pastebin.ca/2430975 (this is in Debian).
>> From this place, doing "n" gdb command several times changes what I declared as const.
>> 
>> This seems to me that, variable "a" and "b" in my code is stored at index 5 and 4 respectively, in global array  "globalTapeVars.store"  inside ADOL-C.
>> By several "n" command  above, changes "globalTapeVars.store[4]", namely "b".
>> The problem seems to be in "next_loc()" function.
>> As argument  x and y (for "adub operator *") are declared as const, it seems next_loc() should
>> return a place that is different from both x's and y's, but in this case it returns the place same as x, and
>> consequently x is overwritten.
>> 
>> (The tail of gdb output at this point is http://pastebin.ca/2430984 (Debian).
>> please compare globalTapeVars.store[4] at the top and at the bottom,
>> and locations of variables x, y, locat at line 5,7,135.)
>> 
>> Regards,
>> Tomita
>> 
>> On 2013/08/12, at 16:35, Norman Goldstein <normvcr at telus.net> wrote:
>> 
>>> That's a nice, clean, valgrind run.
>>> Something next to consider trying is in your debugger,
>>> to put a "change" watch on the variable location
>>> that should be const.  You can set it to break
>>> when the memory location changes value, and
>>> then you can hopefully see who the culprit is.
>>> 
>>> 
>>> On 08/11/2013 10:35 PM, Nozomu Tomita wrote:
>>>> Dear all,
>>>> 
>>>> Thank you for the quick reply.
>>>> I tried valgrind, but (if my usage is correct) it found no error.
>>>> (as I didn't use "new" or "[]" operator, I guess this is not from memory handling in this code)
>>>> 
>>>> I could reduce my previous code...: http://pastebin.ca/2430872 ,
>>>> and its output is this: http://pastebin.ca/2430873 .
>>>> 
>>>> This code does a multiplication with a template class "wrap", for double and adouble.
>>>> Line 15-18 of the output corresponds to line 25-34 of the source, with D == adouble.
>>>> Here a and b changes after multiplication, in spite of its type "wrap<const adouble>"
>>>> (consequently its member is of type "const adouble").
>>>> 
>>>> In this output the results (A's) are not different for double and adouble,
>>>> but it will differ if a or b is used in calculation.
>>>> 
>>>> "make_pair(-A,-A)" at line 32 of the source may be important, because replacing it to
>>>> e.g. "make_pair(A,-A)" or "make_pair(-A,A)" changes output.
>>>> 
>>>> About valgrind, on Fedora on virtual machine (as I couldn't make valgrind work in Mac and Debian), with
>>>> $ valgrind -v ./a.out
>>>> outputted this: http://pastebin.ca/2430874
>>>> 
>>>> I got the same result in previous two environments and on Fedora above.
>>>> 
>>>> Thank you,
>>>> Tomita
>>>> 
>>>> On 2013/08/12, at 0:12, Norman Goldstein <normvcr at telus.net> wrote:
>>>> 
>>>>> Perhaps running a memory checker, such as valgrind on linux, would be insightful?
>>>>> 
>>>>> 
>>>>> On 08/11/2013 12:55 AM, Nozomu Tomita wrote:
>>>>>> Dear all,
>>>>>> 
>>>>>> I'm writing 3-dimensional geometrical calculation, such as how long a line penetrates a box,
>>>>>> with templated class.
>>>>>> 
>>>>>> The problem is that my templated function returns different results for double and adouble,
>>>>>> and "const adouble" quantities seem to change in the middle of calculation.
>>>>>> 
>>>>>> I'm sorry for the mess of source code, but I couldn't pick out the exact place that harms...
>>>>>> 
>>>>>> My code http://pastebin.ca/2430586 is meant to do an identical calculation for both double and adouble,
>>>>>> checking whether a line that is parallel to z-axis and on (1/2, 1/2, 0), penetrates
>>>>>> a square (0,0,0)-(1,0,0)-(1,1,0)-(0,1,0).
>>>>>> 
>>>>>> That returns correctly true for double, but false for adouble.
>>>>>> Compiling this with -DDEBUG produces this output: http://pastebin.ca/2430588
>>>>>> 
>>>>>> Line 55 - 67 of this output correspond to line 173 - 216 of source with template argument Real==adouble.
>>>>>> The Odd thing is that although X and u (and its members) are declared as const,
>>>>>> they change during calculation, from line 57 (u == vector3(0(a), 0(a), 1(a)))
>>>>>> and line 59 (u == vector3(0(a), 0(a), 0(a))).
>>>>>> 
>>>>>> 
>>>>>> I tested this result for ADOL-C 2.4.1 in two environments:
>>>>>> * Debian 6.0.1,
>>>>>>  with g++ (Debian 4.4.5-8) 4.4.5
>>>>>> * MacOS X 10.8.4,
>>>>>>  with g++ i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
>>>>>> 
>>>>>> 
>>>>>> Thank you!
>>>>>> 
>>>>>> Tomita
>>>>>> _______________________________________________
>>>>>> ADOL-C mailing list
>>>>>> ADOL-C at list.coin-or.org
>>>>>> http://list.coin-or.org/mailman/listinfo/adol-c
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> ADOL-C mailing list
>>>>> ADOL-C at list.coin-or.org
>>>>> http://list.coin-or.org/mailman/listinfo/adol-c
>>>> 
>>>> _______________________________________________
>>>> ADOL-C mailing list
>>>> ADOL-C at list.coin-or.org
>>>> http://list.coin-or.org/mailman/listinfo/adol-c
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> ADOL-C mailing list
>>> ADOL-C at list.coin-or.org
>>> http://list.coin-or.org/mailman/listinfo/adol-c
>> 
>> 
>> 
>> _______________________________________________
>> ADOL-C mailing list
>> ADOL-C at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/adol-c
> 
> _______________________________________________
> ADOL-C mailing list
> ADOL-C at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/adol-c

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/adol-c/attachments/20130814/6793e51f/attachment.html>