<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/16/2014 11:55 PM, Kasper
Kristensen wrote:<br>
<br>
<br>
Hi Kaspar,<br>
<br>
Been off hiking for eight days, hence the respite.<br>
<br>
Thanks for the comments. I should explain that where I am
tryhijng to go with this is to anticipate<br>
what problems might be encountered when turning ADMB into a cppad
application rather than the<br>
existing autodif one.<br>
<br>
The LU decomposition comes to mind because it was the first
serious function I needed to write adjoint code for<br>
in order to make autodif useful for what were practical sized
problems at the time. <br>
<br>
The atomic construction you pointed out looks to be really useful
if it works as promised. I'll give it a try.<br>
<br>
Its greatest advantage over autodif (again if it works as
promised) is that with one pice of code it seems possible to<br>
do local forward and reverse model AD of higher order. I had to
code the derivatvies for each of these cases.<br>
<br>
I would like to look at what is involved in getting the Openblas
LU decomp routine modifed to use this feature.<br>
<br>
The idea is to take the blas and turn them into atomic functions
in the cppad sense. Maybe this has already been done?<br>
It seems like an obvious thing.<br>
<br>
First step is to replace the FORTRAN calls in the Lapcake function
to blas in openblas with the C functions in some form of cblas<br>
and make sure thihngs don;t get too slow. Then turn the blas into
atomic functions. any advice you have would be appreciated.<br>
<br>
Cheers,<br>
<br>
Dave<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div>
<blockquote
cite="mid:488F83E988552E45A0E15368C72CA00215A986@ait-pex02mbx05.win.dtu.dk"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;"><font size="2"><span
style="font-size:10pt;">Hi Dave,<br>
<br>
Sorry for re-posting my comments - forgot to cc to developer
list.<br>
<br>
Comments to test case:<br>
1. cppad version: Avoid creating a tape with numerical
overflows by inserting valid parameters for the tape
creation. Or easier: remove the line "det = Scalar( signdet
) * exp( logdet );" to get rid of the overflows (NaNs in the
gradient).<br>
2. The cppad version runs out of memory because this example
tape on the order of n^3 floating point operations. The admb
version avoids this by using adjoint code I believe. Similar
tricks would have to be applied to cppad in order to make
this example run for large n (you can hand code your own
derivatives using cppad's concept of 'user atomic
functions').<br>
3. It would be interesting to compare just the sweep
performance for the two tools, that is just the lines
"dw=f.Reverse(1,w);" and "gradcalc(n*n,g);".<br>
<br>
Comment to this:<br>
"</span></font><font size="2"><span style="font-size:10pt;">I'm
more worried<br>
about how it seems to choke on a matrix a bit bigger than
300x300. Question is whether this is just<br>
due to my naive implementation."<br>
Yes - see point 2. You can reduce the tape size with "user
atomic functions".<br>
<br>
Kasper</span></font><br>
<br>
<br>
</div>
</blockquote>
<br>
</body>
</html>