-
Notifications
You must be signed in to change notification settings - Fork 25
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 a comparison with GAM tools to the docs? #471
Comments
There are different ways to fit GAMs. As far as I understand, |
If this group is interested in including smoothing spline functionality in glum I'd be happy to help out. I put together a guide on how to fit penalized splines using your own custom penalty matrix here: http://statmills.com/2023-11-20-Penalized_Splines_Using_glum/ . While you can theoretically do GAMs in any way with your own penalty matrix I think incorporating separate penalties per smooth term and interaction splines into |
Thanks for the cool tutorial and for the offer to help out here. With the upcoming release of glum v3, there will be two main user interfaces:
With 1., I find the approach in the tutorial quite natural: given that the user already built a model matrix, she can also specify a custom penalty matrix. Here, I see scope for convenience helpers for creating custom penalty matrices though. With 2., it seems more natural to create penalty matrices inside the model, so smoothing or cyclic constraints that work within the formula interface would be welcome contributions! |
I've gotten a few different questions about how glum compares to using something like pygam or whether we have plans to support GAMs:
Strictly speaking, GLMs are a subset of GAMs so this question seems very appropriate. Looking over pygam, for example, a few things seem missing/different:
On the other hand, the space of models described by GAMs is much broader. I might be wrong about these specific points since I'm not experienced with the library.
It would be interesting to do a quick benchmark or even add pygam to the benchmark suite to also have a performance comparison for glum vs pygam. My guess is that glum for GLMs is substantially faster because it's tailored specifically to the problem and also handles the sparsity issues well.
A final question is how much of the feature set (e.g. elastic net regularization along a path) could be ported to the gam setting and whether some of the work we did here could be extended provide a basis for a GAM library.
The text was updated successfully, but these errors were encountered: