Bug in the implementation of pow about tinyad HOT 2 OPEN

Hi Josh,

Thanks for the suggestion! Do you have an example where the original implementation fails? Or is this a performance optimization?

I think in the case e == 1 it should be chain(a.val, (PassiveT)1.0, (PassiveT)1.0, a). Let me know if you agree.

The best way to contribute is by creating a fork followed by a pull request. This way your contributions can be in your name.

Best
Patrick

from tinyad.

I get nans for at least one of these cases with the default implementation. For e==1 if the gradient is constant the hessian should be 0, no?

I created a fork with the code above in the following commit:
the13fools@8d48534

This is the offending code in my codebase: https://github.com/the13fools/gpgpt/blob/main/tools/07_mint3d_v1/src/mint3D_hook/ElementVarsTinyAD.h#L425

Maybe you'll find the way I set it up interesting. Basically I created a "TinyADHook", and then for the per element lambda I created a class that gets instantiated each time to save on boilerplate code. If you have performance suggestions that would be great as TinyAD is quite slow for my use case and it would be nice to speed it up some.

By the way, another question in this vein, is it possible to mix in your own gradients/hessians in some convenient way? I think that would be a really helpful feature to add if not, as it would at least offer a convenient way for me to manually speed up this code.

Another thing that I would love would be the ability to mark dofs as constant and then have the framework generate selection matrices automatically. Right now I'm just setting elements as constant, but this somehow this makes the system harder to solve than it needs to be.

from tinyad.