[Developers] trying to compare autodif with cppad

[dave fournier]

On 08/16/2014 11:55 PM, Kasper Kristensen wrote:


Hi Kaspar,

Been off hiking for eight days, hence the respite.

Thanks for the comments.  I should explain that where I am tryhijng to 
go with this is to anticipate
what problems might be encountered when turning ADMB into a cppad 
application rather than the
existing autodif one.

The LU decomposition comes to mind because it was the first serious 
function I needed to write adjoint code for
in order to make autodif useful for what were practical sized problems 
at the time.

The atomic construction you pointed out looks to be really useful if it 
works as promised. I'll give it a try.

Its greatest advantage over autodif (again if it works as promised) is 
that with one pice of code it seems possible to
do local forward and reverse model AD of higher order.  I had to code 
the derivatvies for each of these cases.

I would like to look at what is involved in getting the Openblas LU 
decomp routine modifed to use this feature.

The idea is to take the blas and turn them into atomic functions in the 
cppad sense.  Maybe this has already been done?
It seems like an obvious thing.

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
and make sure thihngs don;t get too slow.  Then turn the blas into 
atomic functions. any advice you have would be appreciated.

      Cheers,

       Dave






> Hi Dave,
>
> Sorry for re-posting my comments - forgot to cc to developer list.
>
> Comments to test case:
> 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).
> 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').
> 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);".
>
> Comment to this:
> "I'm more worried
> about how it seems to choke on a matrix a bit bigger than 300x300.  
> Question is  whether this is just
> due to my naive implementation."
> Yes - see point 2. You can reduce the tape size with "user atomic 
> functions".
>
> Kasper
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.admb-project.org/pipermail/developers/attachments/20140825/60fddfcd/attachment.html>