-
Notifications
You must be signed in to change notification settings - Fork 11
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
RFC: making parameters subtypes of their originals #74
Comments
I agree with getting rid of the supertyping -- it feels redundant in that I think we really just want a trait-based system. However, I'm not of the opinion that we should start making our types subtype things like |
Hmm I'm not sure I see the downside yet. Wouldn't it just be nice if we could just do |
This is a good point. I'd definitely be interested to see what this would look like in practice. I gues in situations where you don't need parameter tying, this approach works well. It's just that have to be a little bit careful with parameter tying with this kind of approach. e.g. if you want something like kernel(l) = with_lengthscale(SEKernel(), l) + with_lengthscale(Matern12Kernel(), l) it's not clear to me that you can get away with writing it as l = positive(1.0)
k= with_lengthscale(SEKernel(), l) + with_lengthscale(Matern12Kernel(), l) and then trying to extract the fact that you want to tie the lengthscales from |
No, I don't think the latter will work like that. But you could apply the lengthscale to the sum, right? |
Good point. There are definitely presumably more complicated parameter tying settings that you might consider though. e.g. I don't know why you would want this, but something like kernel(a) = a * with_lengthscale(SEKernel(), a) |
I think I know how to address this with something like a |
Oooo I like this |
Lots of low-hanging fruit still hanging around I think :) |
The
AbstractParameters
supertype does not seem to be used and there has not been a need for it in my experience.What if we made the parameters subtypes of their originals, e.g. what if
positive(1.0) isa Real
orpositive_definite(A) isa AbstractMatrix{eltype{A}}
? Overloading methods to arithmetic would make it so we can stick those parameters almost everywhere and be unpacked automatically.The text was updated successfully, but these errors were encountered: