-
Notifications
You must be signed in to change notification settings - Fork 7
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
Ongoing Limitations Issue #31
Comments
It appears these Rmath-related issues apply to all AD backends. https://github.com/TuringLang/DistributionsAD.jl/blob/df19bf48c380a749b5c71e6a63d24b3335a6e65c/test/ad/distributions.jl#L162 Cc @mhauru |
Seems like Tapir doesn't support try/catch (I got a |
Yeah, this should probably be mentioned. Are you able to provide a MWE for this error? I'm aware that we don't handle edit: if I'm remembering correctly (we definitely document this more carefully), you only really get |
My point being that, while we don't have complete support for all |
MWE:
|
This issue is going to remain permanently open. It should not ever be closed. Its purpose is to track known test failure cases, and their causes.
Something can be added to this list only if there is a test in our test suite that cannot pass. That is, if you want to track something that doesn't work, a failing test case must be produced and merged into the test suite.
Distributions.jl
Rmath.dnbeta
,Rmath.dnchisq
,Rmath.dnf
, andRmath.dnt
all useccall
s for which it no one has derived anrrule
-- this is presumably because they involve infinite series, and it is unclear how to write down a rule for them.logpdf
forChernoff
takes a really long time to run. It involves quadrature, so presumably has quite a substantial inner-loop, which is probably why it takes so long.logpdf
forNormalInverseGamma
involves the_besselk
function, which contains accall
for which we have norrule
. Unfortunately, therrule
forbesselk
returns aChainRulesCore.NotImplemented
w.r.t. its first argument. This means that we cannot simply wrap thisrrule
, because we would immediatelyincrement!!
the tangent, which will cause an error to be thrown by ChainRulesCore. In order to support this, we need to modify this framework to permit inactive arguments torrule!!
s, and to take advantage of this in practice.Testing Array / AbstractArray functionality in
Base
and standard libraries\(::Symmetric, ::Matrix)
calls the LAPACK routinesytrf
via accall
. This computes a Bunch-Kauffman factorisation of a symmetric matrix. Unfortunately, this factorisation is somewhat complicated, so writing a rule for it directly (which would be the ideal solution) looks likely to be somewhat involved. It might be that we need to write a rule at a slightly higher level of abstraction -- if we do this, we will need to be careful to restrict the permitted types, and figure out how to handleview
s.aninvoke
call inunique
preventsunique
from being differentiated, asinvoke
is not yet supported by Umlaut.The control flow inResolved by moving to the new way of tracing.Base._unsafe_copyto!
depends on the value of the pointers to the arrays passed in. This effectively means that functions which depend on it, such ascomplex(::Vector{Float64})
, are non-deterministic, because the pointer to the memory allocated to store the result of this operation changes each time the function is run.Misc Rules
Signatures of primals which need rules, but don't yet have them. Other packages (e.g. ChainRules) may have implementations.
Tuple{typeof(Base.FastMath.pow_fast), Float64, Int}
Tuple{typeof(Base.FastMath.rem_fast), Float64, Float64}
The text was updated successfully, but these errors were encountered: