StatsAPI.jl
StatsAPI.jl copied to clipboard
add hasintercept
This is useful to compute the correct degrees of freedoms to be used in t-test
Codecov Report
Patch coverage is 100.00% of modified lines.
| Files Changed | Coverage |
|---|---|
| src/regressionmodel.jl | 100.00% |
:loudspeaker: Thoughts on this report? Let us know!.
Bump.
Moved it to RegressionModel
Btw, note that StatsModels started exporting hasintercept after I wrote this PR. Not sure if this makes it better or not to define it in StatsAPI
How about adding a fallback definition as I proposed above?
Btw, note that StatsModels started exporting hasintercept after I wrote this PR. Not sure if this makes it better or not to define it in StatsAPI
Ah, good point, that's https://github.com/JuliaStats/StatsModels.jl/pull/281. I guess it makes sense to define it in StatsAPI too like the rest of the RegressionModel API, but we will have to import it in StatsModels after tagging a release. AFAICT StatsModels doesn't define any method for RegressionModel, only for terms/formulas.
Thinking about it, it could be better to only have an empty definition here, so that we can define a fallback in StatsModels like this:
function StatsModels.hasintercept(m::RegressionModel)
if formula(m) !== nothing
return hasintercept(formula(m))
else
X = modelmatrix(model)
return any(i -> all(==(1), view(X , :, i)), 1:size(X, 2))
end
end
EDIT: a third possibility would be to add a fallback formula(m::StatisticalModel) = nothing in StatsAPI so that we can have the method above in StatsAPI.
CC: @kleinschmidt @palday
@nalimilan you need requires_one_based_indexing for yours or change it to use axes.
I like the idea of defining a formula stub here. Then downstream packages can do things like define RegressionModels that have a reasonable default formula definition without depending on StatsModels and still optionally supporting the whole Terms interface in extensions.
@kleinschmidt What do you think? I find it relatively unlikely that a package would want to provide an alternative formula implementation. Now that we've decided to put vif and gvif in StatsModels, maybe we should be consistent and put the fallback hasintercept definition there...