I have a local branch where I've been playing around with a fairly massive overhaul of the internals with the following design goals in mind:
Allow arrays used during the fitting process to be freed once the model has been fit. On my branch, I was doing this by defining a Workspace type with methods that allocate storage appropriately for different model structures. A workspace is defined at fit time and passed to various functions but is not stored in the model object itself, allowing it to be GC'd later. Currently model objects store all of that intermediate stuff.
Combine the storage- and factorization-specific types (DensePredChol et al.) into a single LinearPredictor type with parameters that determine eltype, storage, and factorization. I think this would potentially allow more flexibility in terms of extensions, as no new type is needed, just some method definitions.
Remove the response-specific types, LmResp and GlmResp, in favor of storing the relevant bits in the model objects directly. I didn't get this far on my branch. These types always seemed strange to me since weights, for example, aren't really part of the model's response as such. (At least not in my mind.)
Define accessor functions via StatsAPI and use those internally rather than always referencing pp and rr fields. In at least one instance I encountered in the past, the use of .rr internally was incorrect and caused an error, which would have made more sense were it a method error from response.
I figured I'd open this issue in case anybody likes any of these ideas enough to open a PR, since it's quite unlikely that I'll end up getting my local branch to a PR-worthy state.
I have a local branch where I've been playing around with a fairly massive overhaul of the internals with the following design goals in mind:
Workspacetype with methods that allocate storage appropriately for different model structures. A workspace is defined atfittime and passed to various functions but is not stored in the model object itself, allowing it to be GC'd later. Currently model objects store all of that intermediate stuff.DensePredCholet al.) into a singleLinearPredictortype with parameters that determine eltype, storage, and factorization. I think this would potentially allow more flexibility in terms of extensions, as no new type is needed, just some method definitions.LmRespandGlmResp, in favor of storing the relevant bits in the model objects directly. I didn't get this far on my branch. These types always seemed strange to me since weights, for example, aren't really part of the model's response as such. (At least not in my mind.)ppandrrfields. In at least one instance I encountered in the past, the use of.rrinternally was incorrect and caused an error, which would have made more sense were it a method error fromresponse.I figured I'd open this issue in case anybody likes any of these ideas enough to open a PR, since it's quite unlikely that I'll end up getting my local branch to a PR-worthy state.