-
Notifications
You must be signed in to change notification settings - Fork 32
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
[WIP] Use scalar parameters with ParameterHandling #397
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just did a first pass
Two general comments:
- By using
only
we could get rid of a lot of thelength(v) = = 1
- In the composite kernels, instead of
vcat
each of the resulting flattened vectors, why not useflatten
again to get the reconstruction for free
|
||
# or just `@noparams GibbsKernel` - it would be safer since there is no | ||
# default fallback for `flatten` | ||
function ParameterHandling.flatten(::Type{T}, k::GibbsKernel) where {T<:Real} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is flatten
on Function
defined? If yes I think it is fine to throw an error and to tell to implement the needed function for the used struct
|
||
See also: [ParameterHandling.jl](https://github.com/invenia/ParameterHandling.jl) | ||
""" | ||
struct ParameterKernel{P,K} <: Kernel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parameter
or Parametrized
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I chose Parameter
because I felt many kernels are parameterized and hence Paramet(e)rizedKernel
might be confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually didn't we mention another more meaningful name like KernelLayer
or something of this taste? Maybe KernelModel
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think in my initial sketch I used KernelLayer
(probably since we discussed its use with Flux at this point) and in the more concrete suggestion I used KernelModel
. I thought ParameterKernel
was a bit better but I'm not sold on the name and change it to whatever we think is best.
I know, and initially I used it in some places 🙂 However, it requires Julia >= 1.4 and hence does not work with Julia 1.3. |
Since this is going to a be a (massively) breaking release, maybe we can drop support < 1.6 |
I would be fine with this but I didn't want to make this change without prior discussion. Also I assume Julia 1.6 might be the LTS before this PR is ready and merged 🙂 |
|
||
See also: [ParameterHandling.jl](https://github.com/invenia/ParameterHandling.jl) | ||
""" | ||
struct ParameterKernel{P,K} <: Kernel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think in my initial sketch I used KernelLayer
(probably since we discussed its use with Flux at this point) and in the more concrete suggestion I used KernelModel
. I thought ParameterKernel
was a bit better but I'm not sold on the name and change it to whatever we think is best.
Co-authored-by: Théo Galy-Fajou <theo.galyfajou@gmail.com>
Codecov ReportAttention:
... and 21 files with indirect coverage changes 📢 Thoughts on this report? Let us know! |
This PR implements #299 (comment). See the comment and the additional explanations in the issue for more details.
This PR is still WIP and tests will fail (I assume).