Making regress maximally maintainable

[bdwilliamson]

I'm hoping for this to be a place where we can discuss all things regress; in particular, making regress "maximally maintainable". This means (probably) streamlining the internal code and making regress more of a wrapper. But first, some context.

regress was designed as a one-stop shop for all things regression, with

• improved input:
  • the user has to specify a functional of interest (e.g., "odds")
  • standardized arguments across all types of regression
• improved output:
  • robust SEs, confidence intervals by default
  • transformed parameter estimates by default (e.g., the odds ratio rather than the log odds)
• additional functionality:
  • correlated data (through geepack)
  • multiple-partial F tests (for testing subsets of variables at once)

My initial solution to adding multiple-partial F-tests required modifying internal objects from, e.g., glm, including the formula (among others). This, in turn, forced me to lift large amounts of code from these functions to access the objects I needed.

However, I'm now thinking that we could do much more without this. A new workflow could be:

• if a multiple-partial F-test is requested (using U), strip that out of the formula (but hold onto it for later)
• based on the desired functional, fit the stripped down formula using the correct function/package (lm, glm, coxph, GEE using our favorite package)
• compute any multiple-partial F tests (using the correct F statistics from the U term(s))
• create a nice printout table (in a similar manner to before, see here)

This could fix #35: we had to use internal functions from survival, breaking changes of which subsequently broke uwIntroStats and resulted in it being taken down from CRAN.

[bdwilliamson]

Regarding the "best" package to use for fitting GEEs: the options (as far as I know) are

• gee. Pros: well-maintained, similar syntax to glm; often referenced for off-the-shelf GEE software in R; small memory use for small samples. Cons: annoying messages, limits on cluster size (<= 32 for each cluster).
• geeM. Pros: can handle larger cluster sizes than gee. Cons: in my experience, can crash R with lots of data.
• geepack. Pros: can handle larger cluster sizes than gee. Cons: slightly different internal calculations from gee, geeM; can crash R.

Anything I missed? Thoughts on which we should use? (or allow the user to specify? 🤭 )

[taylorokonek]

I think the new workflow sounds nice to me. I have no huge preference on gee package, but I do think it would probably be okay to just use one of them rather than allow the user to specify it. I've personally never used geeM.

On a related note, what are some of the utility functions for regress other than U and testList? I'm going to try to get them all into a regress_utils.R script so it's easier to document and edit things as we move forward

[bdwilliamson]

Here's a list (I think complete) with the function and the desired result:

• U: specify a multiple-partial F test within regress
• testList (currently in listTests.R): fully parse a formula for regress, including breaking out multiple-partial F-tests. Returns a list of tests. Also all other functions in listTests.R, which are all related to parsing formulas for multiple-partial F-tests (could perhaps be simpler)
• termTraverse: helps to create the augCoefficients matrix (for printing regress output)
• pasteTwo: takes in a vector, returns a vector with every two elements pasted together (used in termTraverse)
• all functions in pasting_args.R: for handling splines, dummy variables
• splitOnParen
• explode
• uLRtest: likelihood ratio test
• uResiduals: extract residuals
• uWaldtest: Wald test

We could probably simplify a lot of the string handling by using stringr!

[taylorokonek]

Okay cool, thanks! uResiduals seems to be an exported function that takes in a regress object as an argument, so maybe that can remain in it's own file? The rest of the functions above all seem to be internal, so I'll move them into regress_utils.R... and agreed, a lot of the string handling can probably be simplified!

[bdwilliamson]

Should we support proportional hazards regression and GEEs? @adw96 and @jphughes9 do you know if PH regression and/or GEEs are still introduced in 518?

Arguments in favor:

• PH regression (to some extent) and GEEs (very minimally) used to be introduced in 518
• Could be nice to have unified i/o for the sake of this course

Arguments in opposition:

• these seem like excellent examples for how to load new R packages outside of the rigr ecosystem in a controlled manner
• both are more complex than, e.g., glm, and are more likely to introduce breaking changes
• we probably should introduce students to survival, since that's what they'll use outside of the course
• if we're going to introduce GEEs, it makes sense to use an external package

[jphughes9]

I don’t know about 518 (perhaps check with Katie) but PH regression is introduced in 513. However, I doubt that regress() would be used for that even if available, rather than the survival package. regress() currently supports clustered data and robust variances, right? But all in the context of independent working correlation, I think? I would say good to keep that functionality but not try to turn it into a full gee package. Jim -------------- Jim Hughes Professor of Biostatistics University of Washington Email: ***@***.******@***.***> Mailstop 351617 Phone: 206-616-2721 Seattle, WA 98195 Fax: 206-616-2724 Cell: 206-498-2456 From: Brian Williamson ***@***.***> Sent: Monday, August 2, 2021 11:56 AM To: statdivlab/rigr ***@***.***> Cc: Jim Hughes ***@***.***>; Mention ***@***.***> Subject: Re: [statdivlab/rigr] Making `regress` maximally maintainable (#36) Should we support proportional hazards regression and GEEs? @adw96<https://github.com/adw96> and @jphughes9<https://github.com/jphughes9> do you know if PH regression and/or GEEs are still introduced in 518? Arguments in favor: * PH regression (to some extent) and GEEs (very minimally) used to be introduced in 518 * Could be nice to have unified i/o for the sake of this course Arguments in opposition: * these seem like excellent examples for how to load new R packages outside of the rigr ecosystem in a controlled manner * both are more complex than, e.g., glm, and are more likely to introduce breaking changes * we probably should introduce students to survival, since that's what they'll use outside of the course * if we're going to introduce GEEs, it makes sense to use an external package — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFPGUCRIZAZB2FDDADPBJTDT23S4VANCNFSM5BND6HMQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>.

[adw96]

Hi all - I used survival for my version of 515/518. I just looked at Katie Kerr's notes and she did too. I agree it would be nice have a unified implementation for the sake of teaching, but since we have limited resources for this cause, I'm in favour of ditching PH & GEEs, and referring users elsewhere.

Thanks @bdwilliamson for initiating this conversation and everyone else for your great input. In general I support "maintainability > do-all-the-things" as a philosophy for this package 😊

[taylorokonek]

Related to keeping regress maintainable moving forward, it seems as though the function currently supports (unclear if it's buggy or not... it probably is) linear regression with multiple outcomes, where you can specify a matrix of outcome variables in your regress call. @adw96 @jphughes9 is this something that you go over in your courses, and is this something we want the function to be able to handle moving forward?

[jphughes9]

That is not something I would ever make use of in 511. Jim -------------- Jim Hughes Professor of Biostatistics University of Washington Email: ***@***.******@***.***> Mailstop 351617 Phone: 206-616-2721 Seattle, WA 98195 Fax: 206-616-2724 Cell: 206-498-2456 From: Taylor Okonek ***@***.***> Sent: Wednesday, August 11, 2021 3:35 PM To: statdivlab/rigr ***@***.***> Cc: Jim Hughes ***@***.***>; Mention ***@***.***> Subject: Re: [statdivlab/rigr] Making `regress` maximally maintainable (#36) Related to keeping regress maintainable moving forward, it seems as though the function currently supports (unclear if it's buggy or not... it probably is) linear regression with multiple outcomes, where you can specify a matrix of outcome variables in your regress call. @adw96<https://github.com/adw96> @jphughes9<https://github.com/jphughes9> is this something that you go over in your courses, and is this something we want the function to be able to handle moving forward? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFPGUCRGFCYLISK4CKJZIP3T4L3KTANCNFSM5BND6HMQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>.