`log1pmx` and `logmxp1` cannot be differentiated by `ForwardDiff`

[simsurace]

`log1pmx` and `logmxp1` cannot be differentiated by `ForwardDiff`

[devmotion]

I suppose that defining a diffrule would require one to write an optimized version of the derivative as well, i.e. to calculate the analytical derivative, and try to find an optimal implementation.

IMO the initial implementation does not have to be hyperoptimized. My point was that the computation of the primal will be suboptimal since it will use the generic fallback instead of the Float64 method. I did not want to refer to the computation of the derivative (even though possibly it can be optimized).

The PR does not conflict with such DiffRules additions but in my opinion it's not the correct fix for this issue here, and hence the motivation is a bit different.

Regardless of that, I think it is reasonable to extend them to ::Real. My only concern is that the proposed implementation might not be sufficiently accurate for Float32 and Float16 for which we provide optimized implementations for other functions. It would be good to check that it is sufficiently accurate for these types, and in particular the numerically problematic inputs.

[simsurace]

I'm working on a PR to DiffRules.jl already.

[devmotion]

Will be released in DiffRules 1.11.0: JuliaRegistries/General#59302

[devmotion]

I assume they are missing in DiffRules?

[simsurace]

#45 is sufficient to fix this.

[devmotion]

It will not use the optimized Float64 implementations though which would be used if rules are added in DiffRules. Hence for ForwardDiff support #45 is a bit suboptimal.

[simsurace]

Sure. However, the above tests pass, i.e. using ≈ there are no significant differences with Zygote. So #45 is an intermediate, if suboptimal fix. I suppose that defining a diffrule would require one to write an optimized version of the derivative as well, i.e. to calculate the analytical derivative, and try to find an optimal implementation.

In any case, when someone will have the time and capacity to do this, it will not conflict with the fallback in #45. So the ForwardDiff support is not conflicting with merging #45, is it?