Wrong results when using non numeric type in data structure passed as argument. Some intrinsic limitations ?

[thelfer]

Dear clad community,
I started playing aroung with clad. I made the following test:

#include "clad/Differentiator/Differentiator.h"
#include <iostream>
#include <string>
#include <cmath>

struct Parameters{
  double operator()(const double x) const noexcept { return this->a * std::cos(x); }
  // uncomment to trigger the issue 
  // std::string name = "name";
  double a = 0;
};

int main() {
  // Call clad to generate the derivative of f wrt x.
  auto c = [](const Parameters& p, const double x) { return p(x); };
  auto f_dx = clad::differentiate(+c, 1);
  // Execute the generated derivative function.
  std::cout << f_dx.execute(Parameters{.a = 2}, /*x=*/3) << " "
            << -2 * std::sin(3) << std::endl;
  // Dump the generated derivative code to standard output.
  f_dx.dump();
}

If the name data member is not defined, results are fine. If this parameter is defined, the computed derivative is null. Note that if name is defined as an integer, it works again.

Is there an intrinsic limitations of clad ? If so, is there a way to output a proper error message to the end-user ?

P.S.: Note that this example is mostly a way to circumvent the lack of support of lambda of captures which seems to be on the way of being implemented, which will be super useful.

[gojakuch]

Hi Thomas,

Thanks for opening the discussion.

If the a data member is not defined, results are fine.

I think you meant the name data member, judging from the comment in the code snippet you've provided, because if run on master, this code produces valid results unless one decides to uncomment the std::string name parameter.

As for the issue itself: is there a reason why you are trying to differentiate +c instead of c? That would prevent this issue from occurring.

[thelfer]

I think you meant the name data member

Of course, my bad. I edited the post.

As for the issue itself: is there a reason why you are trying to differentiate +c instead of c?

I wanted to pass a function pointer, nothing more. I could have defined a function, rather than using a lambda.

[thelfer]

I could have defined a function, rather than using a lambda.

With a standard function, it works as expected. This confuses me, the + operator is nothing more than taking the address of the static call operator for capture-less lambdas. Alas, the following code works as expected:

#include "clad/Differentiator/Differentiator.h"
#include <cmath>
#include <iostream>
#include <string>

struct Parameters{
  double operator()(const double x) const noexcept { return this->a * std::cos(x); }
  // uncommenting this line leads to invalid results
  std::string name = "name";
  double a = 0;
};

struct Callable{
  static double f (const Parameters& p, const double x) { return p(x); };
};
  
int main() {
  // Call clad to generate the derivative of f wrt x.
  auto f_dx = clad::differentiate(&Callable::f, 1);
  // Execute the generated derivative function.
  std::cout << f_dx.execute(Parameters{.a = 2}, /*x=*/3) << " "
            << -2 * std::sin(3) << std::endl;
  // Dump the generated derivative code to standard output.
  f_dx.dump();
}

[thelfer]

@gojakuch Do you agree that using +c is valid C++ ? If so, shall I open an issue ?

[gojakuch]

I agree that it's valid C++, although it's a confusing notation for sure. a couple of things though:

1. you don't necessarily need to pass a function pointer to clad::differentiate. the examples you've provided would work with just passing c (not +c) or Callable::f (not &Callable::f) respectively. and while it would work with addresses to some extent, please consider the next point.

2. Clad operates at compile time. that is, we don't really have access to the addresses at all, we can't evaluate that. what is actually passed to the differentiator in the end is the expression you put as the first argument. so even if we provide full support for this sort of expressions (the unary plus), that would be a very specific narrow solution. other expressions that are evaluated to function pointers would still trigger the same behaviour, if not worse.

that being said, you can still open an issue and it would still be appreciated. but there's a (small) chance that it's going to be closed without being addressed, as it's not really a thing that could be universally solved at compile time. maybe it's a valid case to be implemented separately, but there's just no situation I can think of where you wouldn't be able to just provide the lambda itself and not its call operator pointer. and in the cases where there's no way to provide the lambda itself, there's probably no way to determine what to differentiate at compile time either.

[thelfer]

@gojakuch Thanks for your time and detailled answer.
As I felt in this trap in my very first attempt to use clad, I will open an issue for the record, in the hope that it could help other users.

[gojakuch]

@thelfer sure! I'm glad I was able to help. thanks for opening the discussion once again, I think it's a nice case to consider.