-
Notifications
You must be signed in to change notification settings - Fork 6
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
Laplace Approximation intermediates #109
Comments
Could you add a bit more context/details on what made it error ? |
The particular thing I was doing involved some stuff in Stheno.jl, but the issue would have occured if |
using AbstractGPs
using ApproximateGPs
using KernelFunctions
build_latent_gp() = LatentGP(GP(SEKernel()), BernoulliLikelihood(), 1e-8)
x = ColVecs(randn(2, 5))
_, y = rand(build_latent_gp()(x))
build_laplace_objective(build_latent_gp, x, y)() yields ERROR: MethodError: Cannot `convert` an object of type Float64 to an object of type SubArray{Float64, 1, Matrix{Float64}, Tuple{Base.Slice{Base.OneTo{Int64}}, Int64}, true}
Closest candidates are:
convert(::Type{V}, ::CoordinateTransformations.Polar) where V<:(AbstractVector) at ~/.julia/packages/CoordinateTransformations/9po3r/src/coordinatesystems.jl:67
convert(::Type{V}, ::CoordinateTransformations.Cylindrical) where V<:(AbstractVector) at ~/.julia/packages/CoordinateTransformations/9po3r/src/coordinatesystems.jl:270
convert(::Type{V}, ::CoordinateTransformations.Spherical) where V<:(AbstractVector) at ~/.julia/packages/CoordinateTransformations/9po3r/src/coordinatesystems.jl:269
...
Stacktrace:
[1] setindex!(A::Vector{SubArray{Float64, 1, Matrix{Float64}, Tuple{Base.Slice{Base.OneTo{Int64}}, Int64}, true}}, x::Float64, i1::Int64)
@ Base ./array.jl:903
[2] _unsafe_copyto!(dest::Vector{SubArray{Float64, 1, Matrix{Float64}, Tuple{Base.Slice{Base.OneTo{Int64}}, Int64}, true}}, doffs::Int64, src::Vector{Float64}, soffs::Int64, n::Int64)
@ Base ./array.jl:253
[3] unsafe_copyto!
@ ./array.jl:307 [inlined]
[4] _copyto_impl!
@ ./array.jl:331 [inlined]
[5] copyto!
@ ./array.jl:317 [inlined]
[6] copyto!
@ ./array.jl:343 [inlined]
[7] copyto!
@ ./broadcast.jl:954 [inlined]
[8] copyto!
@ ./broadcast.jl:913 [inlined]
[9] materialize!
@ ./broadcast.jl:871 [inlined]
[10] materialize!
@ ./broadcast.jl:868 [inlined]
[11] (::ApproximateGPs.var"#13#16"{Tuple{}, AbstractGPs.LatentFiniteGP{AbstractGPs.FiniteGP{GP{AbstractGPs.ZeroMean{Float64}, SqExponentialKernel{Distances.Euclidean}}, ColVecs{Float64, Matrix{Float64}, SubArray{Float64, 1, Matrix{Float64}, Tuple{Base.Slice{Base.OneTo{Int64}}, Int64}, true}}, Diagonal{Float64, FillArrays.Fill{Float64, 1, Tuple{Base.OneTo{Int64}}}}}, BernoulliLikelihood{LogisticLink}}, Vector{SubArray{Float64, 1, Matrix{Float64}, Tuple{Base.Slice{Base.OneTo{Int64}}, Int64}, true}}})()
@ ApproximateGPs ~/.julia/packages/ApproximateGPs/XL25n/src/laplace.jl:83
[12] ignore_derivatives
@ ~/.julia/packages/ChainRulesCore/uxrij/src/ignore_derivatives.jl:26 [inlined]
[13] (::ApproximateGPs.var"#objective#15"{Bool, Nothing, Int64, Vector{SubArray{Float64, 1, Matrix{Float64}, Tuple{Base.Slice{Base.OneTo{Int64}}, Int64}, true}}, typeof(build_latent_gp), ColVecs{Float64, Matrix{Float64}, SubArray{Float64, 1, Matrix{Float64}, Tuple{Base.Slice{Base.OneTo{Int64}}, Int64}, true}}, Vector{Bool}})()
@ ApproximateGPs ~/.julia/packages/ApproximateGPs/XL25n/src/laplace.jl:78
[14] top-level scope
@ REPL[80]:1 |
st--
added a commit
that referenced
this issue
Mar 21, 2022
Fixes #109 Breaking change (required for bugfix): when using `objective = build_laplace_objective(...)` and wanting to access the final `f`, you now need to access `objective.cache.f` instead of `objective.f`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As noted in the code, this line makes quite strong assumptions about
x
ApproximateGPs.jl/src/laplace.jl
Line 60 in bae0a1e
When I went to use the laplace approximation code I initially stumbled around with it for a while, before realising I could just call
build_laplace_objective!
, and buildf
myself.I'm not entirely sure what a proper fix that gives the correct initialisation all of the time would look like, but I think we can tell when it's definitely going to produce an error downstream, because I'm pretty sure we'll get an error if the element type of
xs
isn't a subtype ofReal
? Should we perhaps check this case, and provide a useful error message if it's hit?@st-- ?
The text was updated successfully, but these errors were encountered: