Start exposition of complex Scalar types for autodiff

[jcarpent]

@cmastalli One step towards the exposition of complex Scalar types

[cmastalli]

Thank you for pushing this forward.

Do you think it would help to divide it into tasks and report them using Actions?

I would like to help you more :)

[jcarpent]

What do you mean by Actions?
We can divide into tasks of course, but the first thing to know is how much you can contribute? On which side?
I think the first step is to understand the existing code, how to transfer from C++ to Python and vice-versa. I let you read the code and experiment by yourself.

[cmastalli]

GitHub actions.

Yes, I will spend time for understanding the code.

[jcarpent]

The first stage to register user types is done now. @nim65s Could you try the new devel branch on your infrastructure to get quick feedback if everything remains stable? Normally, I did not change the core.

[cmastalli]

@jcarpent -- with this stage, could be possible to interface eigenpy with other types (e.g. pyadolc or cppad_py)?

The former is done through Boost Python, the latter through Swig.

[nim65s]

@jcarpent I will. I should be able to provide an answer tomorrow.

[jcarpent]

@jcarpent -- with this stage, could be possible to interface eigenpy with other types (e.g. pyadolc or cppad_py)?

For the former, no problem I would say. For the second, I've checked the implementation and it does not seem suited to our purpose of using CppAD<any_scalar> for CppADCodeGen mainly.
In addition, there is no sharing of the memory at all between Numpy and Eigen.
I would rather suggest providing a generic implementation with visitor to allow any exposition.
@cmastalli Do you agree on this analysis?

[cmastalli]

For the former, no problem I would say.

I will test it asap.

it does not seem suited to our purpose of using CppAD<any_scalar> for CppADCodeGen mainly.

Yes, they don't support CppADCodeGen. I asked yesterday about it, and the answer was "we're not planning to do it in the near future". My question was more about the used of Swig, because we could still help to provide that support.

@cmastalli Do you agree on this analysis?

Yes, I do 👍

[jcarpent]

According to bradbell/cppad_py#10, it seems that we will need to provide our own bindings for it, with full template support to avoid useless dupliacations, but not the priority now.

[nim65s]

The first stage to register user types is done now. @nim65s Could you try the new devel branch on your infrastructure to get quick feedback if everything remains stable? Normally, I did not change the core.

I can confirm that the current devel branch didn't break anything in any build nor in any unit test of any package that I maintain, on their respective latest released version, on 16.04 & python 2, and also on 18.04 & python 3 :)

[jcarpent]

Very helpful feedback @nim65s. Thank you very much!

[nim65s]

You're welcome.

I have now a really easy way to run this, so please don't hesitate to ask for it when you have any doubt :)