-
Notifications
You must be signed in to change notification settings - Fork 5
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 additional links #170
Comments
Hey @danielinteractive , Would you mind clarifying what you mean by
The current random-slope link contribution is: Where:
Am I right in thinking you mean an alternative as |
That is exactly correct |
Potentially blocked by #238 - Well its not blocked but it would be preferably to do 238 before doing this one to reduce the amount of backtracking required. |
@danielinteractive Wondering about how to structure this. For:
I am wondering if its worth just doing a
I guess in theory the other 2 can be wrapped up in this frame work as well like:
I guess this is a bit clunky though because you could argue well why isn't "identity" put under this framework as well... ? |
@danielinteractive - Apologies but would it be possible to get your thoughts on the above ? |
Hm that looks a bit clunky to me. I thought we have now methods for these links? I would rather like to see an API where each different link has another generic/method name. |
@danielinteractive - So if I was to implement this as distinct methods we would likely have:
I guess my reservation is that these are quite model specific e.g. it will be a generic for a single method implementation and it will be quite clunky to know which methods work with which models outside of digging into the documentation. I mean, having said that I'm not sure I have a good alternative... Having written that, would I be right in saying that in the case of the random slope model |
Yes, I would recommend going this route. You can easily query using standard R methods stuff what works where. Yes to your specific question. |
I should add though you can't use the standard method querying stuff because these user facing functions are actually just general functions that wrap the underlying generics (this was done to provide a convenience layer for users to ease the UI). E.g. the users don't interact with the true generics which are |
Hm, I see... and we cannot / don't want to expose the true generics?... Just wondering if that would be long term easier to maintain as well |
At the time there was a very good reason.... I'm struggling to remember it now though, it was technical in nature. I'm going to double check the notes to see if I can remember why as I agree it would be cleaner if we just had straight generic methods being specified by the user... |
@danielinteractive , From what I can tell I did this as a UI/UX trade off. Originally I wanted to avoid the user having to manually execute the generics themselves as I was worried it was a bit clunky from a syntax point of view, for example I was trying to avoid:
Ideally what I would want this to be is something more like...
The problem with this though is prior specification. If you are passing unevaluated generic functions as inputs then there is no way for the users to specify the priors. So instead I opted for closure functions for the generics that enclose the prior e.g.
Where roughly:
Basically if we want the user to pass the generic functions themselves as inputs then we need the user to evaluate the generic against the model themselves so they can pass a prior as well. Going over all this again I'm not actually sure what I prefer... I don't like the fact we have 2 layers of functions as this is complicated to understand from a extending point of view and makes method discovery difficult. But I also don't like getting the user to have to invoke the generic themselves as this is clunky syntax and potentially an error source if users copy code forward and evaluate the generic against the wrong model objects. |
Hm I think it would be ok to pass |
Ok after playing around with this quite a bit I think I found a solution that gets the best of both worlds. Some toy example code to demonstrate the point:
Essentially if the user doesn't provide a model argument to the link method then it falls to the default method which returns a closure that has the prior embedded in it which just calls itself again. |
I would still question whether this warrants the additional complexity... |
Personally I really dislike the idea of the user having to potentially specify the longitudinal model is so many places:
My gut feeling just says this is clunky and likely to be error prone. |
You can decide, I guess we thought about it sufficiently |
To do:
The text was updated successfully, but these errors were encountered: