Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Path towards GLMs with fweights, pweights, and aweights #186

Open
jeffwong opened this issue Jul 15, 2017 · 4 comments · May be fixed by #487
Open

Path towards GLMs with fweights, pweights, and aweights #186

jeffwong opened this issue Jul 15, 2017 · 4 comments · May be fixed by #487
Labels
breaking enhancement
Milestone
Release 2.0

Comments

@jeffwong
Copy link

This ticket is related to this discourse discussion

From what I can tell

  1. We need to expand LmResp and GLMResp to not only contain wts, but also contain fweights, pweights, and aweights. We should allow a user to pass in multiple types of weights like both fweights and pweights.

  2. We will need to have a function that consolidates fweights, pweights, and aweights into a single vector that can be used in a more classic setting like weighted maximum likelihood. In MLE, only the relative weighting of the weights matter, not the absolute value. If someone is combining fweights and pweights I think this can be consolidated through wts = fweights * pweights. Second opinion welcome here!

  3. The MLE functions already accommodate a weight vector, so nothing needs to be done here if 2) is done

  4. The nobs function currently returns the sum of wts, if present. This is the right behavior for fweights. For pweights and aweights, I think we need to return the number of rows in the LinPred object.

  5. We will need to adapt the vcov function to return the covariance matrix according to the types of weights used. Here is a reference
@ararslan
Copy link
Member

As a reference to other readers, see also JuliaStats/StatsBase.jl#283

@nalimilan
Copy link
Member

Thanks for writing this. I agree in general. Just a few remarks:

We need to expand LmResp and GLMResp to not only contain wts, but also contain fweights, pweights, and aweights. We should allow a user to pass in multiple types of weights like both fweights and pweights.

Do we actually need to store the three vectors? Maybe we could only store one vector, after adjusting it to take into account the other (if they were specified), as in point 2?

The nobs function currently returns the sum of wts, if present. This is the right behavior for fweights. For pweights and aweights, I think we need to return the number of rows in the LinPred object.

More precisely, I think that should be the number of nonzero weights.

@jeffwong
Copy link
Author

  1. Yes that is a really good point. I suppose there aren't many use cases where it is useful to extract out the original fweight, pweights, and aweights. If anyone thinks of a scenario where these are needed leave a note

  2. Yes I think you are right

I have parts 1-4 done, just trying to figure out exactly how the vcov function works

@jeffwong jeffwong mentioned this issue Aug 13, 2017
Closed
@Nosferican
Copy link
Contributor

What about rather than passing a linear predictor and weights, we just return the weighted model matrix? If I am not mistaken, it should just make it simpler for vcov.

This was referenced Sep 3, 2022
Closed
Open
@andreasnoack andreasnoack added this to the Release 2.0 milestone Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
breaking enhancement
Projects
None yet
Milestone
Release 2.0
Development

Successfully merging a pull request may close this issue.

Taking weighting seriously gragusa/GLM.jl
5 participants
@jeffwong @andreasnoack @nalimilan @Nosferican @ararslan