-
Notifications
You must be signed in to change notification settings - Fork 0
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
Terms with multiple smooth objects #16
Comments
you will get multiple smooth terms for |
|
Did you just write this up? Awesome! I'll go through in more detail. I would also like to have some "keywords" for commonly used types of transformations. e.g., "linear", "quadratic", etc. Can you tell me where it is documented on how to define a new I wonder if I should do something like this for my variable-domain regression stuff. In fact, I probably could do the variable-domain regression with the same basis construction as this one. |
|
Right, I forgot about factors, I knew there was a good reason. I was just playing around with The reason that I am keeping this extra level of indexing around is because I wanted the length of the |
I am finally getting around to finalizing the code you wrote for the Also, a couple other comments/questions on this:
I am also going to create another basis for "domain transformation" ( The implementation of
or something like that. Then our code would pass all 4 variables into each function to get the transformed variables. Eventually I want to be able to fit a model with |
Nice! testing-code didn't really work, though. y u so sloppy? 😉
yes,
You confused yourself there, the code in /Testing didn't run because you mixed
Not sure I understand what you mean.
Maybe once it's more mature. Then again, if you use the |
nice!
Sweet jesus. You're right, I guess. What's the use case for that kind of complexity, though?
I can see why that would be a desirable option. There's a big danger here, though, that you/we are adding lots of complex features onto a not-really-all-that-stable codebase. Another point to consider, depending also on how much more time you can spend on this project before you start your new job, is what's more important: being able to fit every conceivable kind of complex effect or having easy-to-use and well-designed |
You're right, of course, that the package needs cleaning up, and I guess I'm guilty of trying to add too much complexity right away. It would definitely have been better to get some basic stuff working fully before trying to add in all these features. This is a big "lesson" that I've learned from this whole project! Get the basics working first, then add functionality later. That being said, the main reason I want to implement all this domain-transformation stuff is because I want to fit those models now (as in, before I have to turn in my thesis in a few weeks). I found that, in particular, standardizing and parameterizing the domain resulted in better-fitting models for the variable-domain model (with death as a binary outcome), and I suspect the same thing will happen here (at least I hope so). The biggest gain was for the "domain standardized" model. In the variable-domain paper, I did this by a "change of variable" substitution, defining
The reason I showed the example for a transformation of a smooth of 4 variables was because I just figured if I was going to implement this now for a bivariate smooth, I might as well implement it to be flexible enough to handle an arbitrary number of variables. It's not terribly more difficult to program it that way. But no, I don't have any need for that kind of complexity now (and maybe nobody ever will).
I didn't exactly confuse myself, but I changed my mind after I wrote the last comment. I decided to make the basis work for an arbitrary number of variables, so
Yeah, I decided to go with the easier route, which was to just save the smooth object for the "reduced" smooth in the |
Going back to the "pi" basis, which we discussed above. Recall that for a smooth with a parametric interaction, we are using the same smoothing parameter to penalized each of the reduced-dimension smooths. In other words, if we have I am now giving the option to relax this, and to use a different smoothing parameter for each
Just confirming, this should work, right? It seems like a convenient way to fit multiple smooths (which more generally don't even have to be related to one another) in the same |
seems fine, yet inefficient. linking smooths via "id" would prob. be the On Wed, Apr 22, 2015 at 11:38 PM, jgellar notifications@github.com wrote:
|
Linking smooths with When you say this would be "inefficient", do you mean it would fit slower, because of the unnecessarily large matrices involved? I still think this is the only way to do it and have it all contained in a single basis object, which is what we need for user transparency. Maybe we could gain some speed if we define things as sparse matrices using the |
|
This has been implemented |
As you see from the recent updates, I'm finally getting a chance to get back into
pcox
. I'm working on changing functionality to accommodate methods now (in particularpredict.pcox()
, but it will be useful for other methods as well). One of the big changes that I made is that instead of just havingtt
functions for time-varying terms, I also am now creatingxt
functions (viacreate.xt.func
) for "x-transformations" - these are variables that don't require a "time-transformation" (tt
). These are a lot simpler than thett
functions because they can be executed withinpcox
instead of having to go throughcoxph
.One other quick question, I think I brought this up at some point in Munich but I wanted to revisit. When we create a smooth term via
smoothCon()
, it comes out as a list with a single element. Is there any reason that we couldn't just pull out the smooth from the list? I know thatmgcv
does this because occasionally there are terms that have more than one smooth associated with them. Will we ever have this? I can't remember exactly when this type of term would occur, or if it's relevant for us. It is just annoying to have to have to remember that extra indexing ([[1]]
) every time I want to access the smooth object.The only time that I can think of where multiple smooth objects would be needed is for "parameterized" interactions. I haven't implemented this functionality yet, but what I mean by that is that we make an assumption about$\beta(s,t)$ , e.g., $\beta(s,t) = \beta_1(s) + t*\beta_2(s)$ (i.e., a linear interaction with time). Then a basis would be fit to both $\beta_1(s)$ and $\beta_2(s)$ . However, for cases like this I think it would be desirable to only use a single smoothing parameter for the two terms. This would allow us to reduce the whole thing to a single smooth object with a block diagonal penalty matrix. We talked about this a little in person.
For what I described in the preceding paragraph, could this be accomplished by defining a "user-defined"
smooth.construct()
function? I've never done this, but I know it's possible (and I know that you have!). It would be awesome if we could do this in a flexible way where the user could decide how the bivariate coefficient function is parameterized. This seems tricky though.The text was updated successfully, but these errors were encountered: