Re: Algorithmic Differentiation in Octave

[Olaf Till]

On Sat, Feb 04, 2017 at 06:32:09AM -0700, Brad Bell wrote:
> 
> Did your run the following command ?
>     make check_lib_octave
> (see same question below)

See below.

> On 02/04/2017 05:48 AM, Olaf Till wrote:
> >On Sat, Jan 28, 2017 at 09:42:43AM +0100, Olaf Till wrote:
> >>For finding an overall way to fit this into Octave, I still have to
> >>find out about some issues in your interface which are not clear to
> >>me. But before asking, I'd like to give it a try, making it compile
> >>and experimenting with it a bit. Since I have currently some other
> >>things on my schedule, I guess it'll take a week.
> >I havn't come very far. The cppad library, compiled according to the
> >instructions at
> >
> >https://www.coin-or.org/CppAD/Doc/cmake.htm
> >
> >with
> >
> >cd build
> >cmake -G "Unix Makefiles" -D cppad_prefix=/usr/local ..
> >
> >with 'make install' only installs headers, no library. And I find no
> >library even under the build/directory.
>
> Cppad is a header only package.

Ok, I didn't expect this. But still, although a file in cppad_swig
included 'cppad.hpp', an oct-file was compiled even at the time when
no cppad.hpp was present on my system (in the last compilations it was
present, of course).

> ...
> >
> >swig-cppad compiled an oct-file, after fiddling with Octaves include
> >files. (BTW: Instead of `octave-config -p INCLUDEDIR`, use `mkoctfile
> >-p INCFLAGS`, yielding 2 include dirs, with '-I' already prepended.
> Thanks, I will give this a try.
> >
> >swig-cppad compiled this although no cppad library was present
> >anywhere, and not even the cppad headers were present at this time
> >(and I don't find them in swig-cppad either)! The resulting oct-file,
> >according to 'ldd', referenced nothing which looked like a cppad
> >library, of course. And it segfaulted at the time of loading into
> >Octave.
>
> See the heading Testing on
>     http://www.seanet.com/~bradbell/cppad_swig/cppad_swig.htm
> When you run
>     bin/run_cmake.sh
> there will a list of available make commands (for your configuration).
> 
> Did your run the following command ?
>     make check_lib_octave

No, first 'make auto_lib_octave', then 'make
check_swig_xam_octave'. Now I've run 'make check_lib_octave' also.

For compilation to succeed, I put the lines

#include <octave/oct-alloc.h>

#undef HAVE_HDF5

#include <limits.h>

into the generated 'cppad_swigOCTAVE_wrap.cxx'.

> This should build all the example *.m files, the octave swig interface, and
> run the tests.

Yes. But the tests make Octave segfault, just as my previous manual
tests.

> ...
> >So I can only give 'theoretical' notes now.
> >
> >Let's assume swig-cppad worked as expected. Then, if we took it
> >unchanged, we'd have to define a wrapper class around it. Doing this
> >in iterpreted Octave code would yield matrix operations which are too
> >slow.
>
> I thought that Octave would automatically generate matrix operations in C++
> that used the overloaded classes (as numpy does for python) ?

That is a misunderstanding. (In jwe's example, in the line
'numeric_result = builtin ('mtimes', x.data, y.data);', x.data and
y.data refer to Octaves _native_ matrix type.)

Even only to _generate_ a matrix type which contains elements of a
type corresponding to 'a_double', one has to define the matrix type
manually in Octaves C++ API. And, after the Octave interpreter
commands:

  ax = m_cppad.independent(x);

, for the concatenation in the command:

  A = [ ax(0), ax(1) ; ax(2), ax(3) ];

to work, the a_double type would have to have certain methods defined
-- without looking into the source now I think it was at least the
resize() method. The resize() method would have to produce an object
of our new matrix type (which also must have the resize() method,
BTW).

More directly, our newly defined matrix type could be generated from
'a_double_vec' by a function (written in C++), say 'm_a_double':

  m_ax = m_a_double (m_cppad.independent (x));

  A = [ m_ax(0), m_ax(1) ; m_ax(2), m_ax(3) ];

And a method for matrix multiplication, e.g., must also be implemented
manually for the new matrix type.

> >I think the best bet would be to generate an Octave type at the c++
> >level (similar to what swig-cppad currently does) which interfaces to
> >cppad and already contains overloading of matrix operations.
> >
> >If the latter is done, I would not like to do it with swig, but rather
> >try it directly with Octaves API. And the build system of swig-cppad
> >would have to be changed anyway, IMHO, to make it distributable as an
> >Octave package.ld
>
> I defined a very lightweight (and I think efficient) interface from the
> Cppad Swig library to any language. I figured that this would greatly reduce
> the work involved in make taped AD available in not only available in
> python, but other languages as well.

Yes... but as you probably see now, for Octave, there is much that has
to be changed at the C++ level. I can only speek for me -- if I'd have
to do it, I'd prefer doing it by directly using the Octave API. It's
possibly mainly because I'm not familiar with swig; but maybe also a
personal preference to control the code better.

I have also a certain fear that swig might not immediately work with
future versions of the Octave API.

I can't comment on the other languages.

> > ...
> >Problems are that cppad currently installs no library for me (see
> >above), and that cppad doesn't seem to be available in current Debian
> >(i.e. only the headers are available there).
>
> See
>    https://tracker.debian.org/pkg/cppad

You explained to me above that it's a header only package. So I agree
it's available in Debian.

Olaf

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

signature.asc
Description: Digital signature