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

Mon Aug 12 16:44:02 EDT 2013

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 
> <http://pastebin.ca/2430974> (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 
> <mailto: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 
>>> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/20130812/01ff6ce0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4243 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://list.coin-or.org/pipermail/adol-c/attachments/20130812/01ff6ce0/attachment.p7s>