help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Algorithmic Differentiation in Octave


From: Joel Andersson
Subject: Re: Algorithmic Differentiation in Octave
Date: Tue, 24 Jan 2017 14:03:14 -0600

There are actually two ways to generate Octave bindings using SWIG. One is indeed to use the Octave module, but I'm not a great fan of this module since the generated code doesn't have a very intuitive syntax IMO. The other way is to use the MATLAB package, which myself and others have been developing for some time. It's not yet merged with the SWIG main branch so you'd have to have a look at e.g. https://github.com/jaeandersson/swig. While originally written for MATLAB, it has now been modified to generate code that is MATLAB/Octave bilingual. This has been made possible thanks to Octave's support for MEX and MATLAB-style object oriented programming.

It's unlikely to compete very favourably in speed with the existing Octave module, but I'd say that the syntax is much more natural and the calling overhead is often not a bottleneck when interfacing code. Being able to generate code that is both valid Octave and MATLAB has also been very important for us. We use the SWIG-MATLAB/Octave module to generate bindings for CasADi, an open-source tool for numerical optimization which also includes algorithmic differentiation. It's more than a bit of a pain to compile the module, but most (if not all) of our Octave users would just download the precompiled binaries from our website: https://github.com/casadi/casadi/wiki/InstallationInstructions

Best regards,
Joel




2017-01-24 13:32 GMT-06:00 Olaf Till <address@hidden>:
On Tue, Jan 24, 2017 at 11:44:20AM -0700, Brad Bell wrote:
> On 01/24/2017 11:03 AM, Olaf Till wrote:
> >On Tue, Jan 24, 2017 at 08:35:09AM -0700, Brad Bell wrote:
> >>I have created a link from Cppad
> >>     https://www.coin-or.org/CppAD/
> >>to Octave (and some other languages) through Swig. See
> >>     http://www.seanet.com/~bradbell/cppad_swig/cppad_swig.htm
> >>Also see the getting started example for Octave
> >>http://www.seanet.com/~bradbell/cppad_swig/a_fun_jacobian_xam.m.htm
> >>
> >>Feel free to contact me if you have any questions about it.
> >>
> >>Brad.
> >I thought of implementing AD myself for Octave some time... The
> >natural concept seems to me to have classes whose objects
> >(representing vectors) you can give as arguments to a general scripted
> >function (restriction: function must only use operations which are
> >overloaded for the object) making this function return the
> >derivatives.
>
> I think you are referring what is called tapeless forward mode AD; see
>     https://goo.gl/rqc2Dl
>
> >  Your concept seems to be different, and more complicated
> >for application -- it seems to involve creation of a separate
> >representation of the function code ('ay(0) = ax_0 * ax_1 * ax_2; af =
> >m_cppad.a_fun(ax, ay);' in your example)...?
> Yes, the function is taped (recorded). Once it is taped, it can be
> optimized, sparsity patterns can be computed, and derivatives, or all
> orders, and that take advantage of sparsity, can be calculated. In addition,
> the function can be evaluated (with C++ like speed) at different points
> (provided that the operation sequence does not depend on the independent
> variables):
> https://www.coin-or.org/CppAD/Doc/glossary.xml#Operation.Sequence

Thanks for the explanation. Sounds good. Maybe we'll find a way to
automatize the 'taping' of all code within the body of a scripted
function... Then we could have a package which conveniently provides
both your implementation and what I've learned is called 'tapeless
forward mode'. I think the latter is still useful -- AD is most needed
for large, computationally intensive, functions, and in those it is
very likely that the operation sequence does depend on the independent
variables.

It seems you've been able to create Octave plugins with swig. There
have been problems in the past with swig and Octave. I don't know the
current state. But it makes me a bit uneasy to depend on swig being
up-to-date with Octave, since AFAIK the Octave part of swig is
maintained independently from Octave. But maybe we could use the
generated code directly for adaptions to future Octave versions, if
swig should not be up-to-date anymore.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

_______________________________________________
Help-octave mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/help-octave




reply via email to

[Prev in Thread] Current Thread [Next in Thread]