Hi,

I don’t use any of the “tidyverse” functionality, so I can’t help you with the particular function, or perhaps relevant modifications to it. That function appears to have been coded to work with glm() derived objects in R, not lm() or ols() objects, and there are subtle and not so subtle structural differences in them, depending upon the complexity of the model being created.

One step to try, at least initially, is to see if that function will work with your model having been created using the standard R function lm() as opposed to Frank’s ols() function. That might give you a hint as to a direction to take here.

In general, to get the reference levels for any factors in the model, you would need to find out where those values are stored in the resultant model object, which in the case of the standard lm() and glm() functions in R, is in the “xlevels” part of the returned model object and that is referenced in the code for the function in the SO thread.

That is MOD$xlevels, where MOD is the returned lm() or glm() model object, and then process that accordingly to insert those values into the rows of the standard coefficient matrix as desired.

Using the standard R model functions, you would get the matrix of coefficients and associated statistics using coef(summary(MOD)), again where MOD is the returned model object.

You would then want to use the relevant print function to output that modified matrix, which in the case of standard lm() output is going to be the printCoefmat() function. Otherwise, you would potentially need to write your own print function to output the modified matrix in a formatted manner, which just adds to the amount of work that you would need to do here.

From a quick test using ols() on one of the model examples in lm(), where there is a factor used, it would suggest that the relevant factor level information is stored in MOD$Design$parms of the returned ols() model object, where there are sub-elements for each factor in the model formula.

If that is correct, it would explain why that function in the SO thread does not work, since the model object structure returned from ols() differs materially from lm(), and I would envision that is the case to support other functionality in Frank’s rms package, such as penalties and so forth.

The above might give you enough hints as to how to modify that SO function, but you may have to dig a bit deeper there, if you wish to pursue that path.