You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wanted to get some feedback and thoughts on how best port the information I give for the estimators in Econometrics.jl (see examples). These models cover the ones supported by FixedEffectsModels (e.g., instrumental variables, absorption of features, robust variance covariance estimators) as well as some of the nonlinear models in GLM.jl (e.g., discrete choice models). Would it be best to work on implementing the API?
The text was updated successfully, but these errors were encountered:
I think a TableRegressionModel is a good interface for nonlinear model estimates. If you want to show more statistics, we can probably add them in the footer of the table through the regression_statistics option.
Any reason why the API should be at TableRegressionModel?
struct TableRegressionModel{M,T} <: RegressionModel
model::M
mf::ModelFrame
mm::ModelMatrix{T}
end
Those structs don't play that nicely with instrumental variables, not a single ModelFrame/ModelMatrix which are legacy as the new recommended method is modelcols.
Is there any advantage to that over the CoefTable which is part of the API? TableRegressionModel is at StatsModels and technically not part of the abstraction for RegressionModel?
I wanted to get some feedback and thoughts on how best port the information I give for the estimators in Econometrics.jl (see examples). These models cover the ones supported by FixedEffectsModels (e.g., instrumental variables, absorption of features, robust variance covariance estimators) as well as some of the nonlinear models in GLM.jl (e.g., discrete choice models). Would it be best to work on implementing the API?
The text was updated successfully, but these errors were encountered: