Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add definition for logabsgamma #585

Merged
merged 4 commits into from
May 18, 2022
Merged

Add definition for logabsgamma #585

merged 4 commits into from
May 18, 2022

Conversation

devmotion
Copy link
Member

This PR adds a definition of SpecialFunctions.logabsgamma(::Dual). SpecialFunctions is a dependency of ForwardDiff already, and in constrast to most other functions in SpecialFunctions derivatives of logabsgamma can't be defined via DiffRules since logabsgamma is not a real-valued function but returns a tuple (log(abs(gamma(x)), sign(gamma(x))).

function SpecialFunctions.logabsgamma(d::Dual{T,<:Real}) where {T}
x = value(d)
y, s = SpecialFunctions.logabsgamma(x)
return (Dual{T}(y, SpecialFunctions.digamma(x) * partials(d)), s)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should return rather

Suggested change
return (Dual{T}(y, SpecialFunctions.digamma(x) * partials(d)), s)
return (Dual{T}(y, SpecialFunctions.digamma(x) * partials(d)), Dual{T}(s, zero(s)))

to be consistent with sign(::Dual)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it doesn't really matter one way or the other does it? promotion will fix it when it matters.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't think it matters. It felt easier for downstream computations and somewhat stronger to drop the partials completely. Only afterwards I noticed the inconsistency with sign and started to wonder if we should return a zero partial instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.... Maybe we should be consistent with sign at all since it makes a difference in an example such as:

julia> using ForwardDiff

julia> f(x) = Inf * x
f (generic function with 1 method)

julia> g(x) = sign(x)
g (generic function with 1 method)

julia> g(x::ForwardDiff.Dual) = sign(ForwardDiff.value(x))
g (generic function with 2 methods)

julia> ForwardDiff.derivative(f  g, 1.0)
0.0

julia> ForwardDiff.derivative(f  sign, 1.0)
NaN

The "stronger" definition that drops the partial completely doesn't run into the NaN-safe mode issues and hence does not care about the non-finite result.

Maybe it's an argument for defining

Base.sign(x::Dual{<:Any,<:Real}) = sign(value(x))

rather than changing this PR though.

@codecov-commenter
Copy link

codecov-commenter commented May 6, 2022

Codecov Report

Merging #585 (fe19760) into master (4ba6c90) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #585      +/-   ##
==========================================
+ Coverage   86.57%   86.63%   +0.05%     
==========================================
  Files           9        9              
  Lines         894      898       +4     
==========================================
+ Hits          774      778       +4     
  Misses        120      120              
Impacted Files Coverage Δ
src/dual.jl 79.46% <100.00%> (+0.24%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4ba6c90...fe19760. Read the comment docs.

test/DualTest.jl Outdated Show resolved Hide resolved
Copy link
Member

@oxinabox oxinabox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a regular committer here.
But the math on this checks out,
and other than one comment on style, I think the tests look sufficient.

I would say give this a little time, then merge it if noone else raising objections.
Maybe 1 more day, since it has been open 7 days already.

Co-authored-by: Frames Catherine White <oxinabox@ucc.asn.au>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants