JuliaGaussianProcesses / ParameterHandling.jl

Foundational tooling for handling collections of parameters in models
MIT License
72 stars 11 forks source link

RFC: file structure #44

Closed st-- closed 2 years ago

st-- commented 3 years ago

Currently, the code is split across four files:

Following the discussion around positive_definite in #41, it seems that we might turn this into several: lower_triangular (no constraint on diagonal), lower_triangular_positive_diag (positive diagonal), and positive_definite for returning a PDMat.

Before making parameters.jl even longer (I already find it to be at if not above the upper end of how large a file can be to still keep a good overview of disparate content), I was wondering if it might make sense to split up parameters.jl - there's of course plenty of options, here's the ones I can see immediately:

A: one file per "item", i.e. perhaps base.jl for AbstractParameter and value() for base types, then positive.jl, bounded.jl, fixed.jl, etc.

B: grouped into less files, perhaps as follows:

C: status quo.

It would also be an option (composable with any of the above) to move some of the base definitions, e.g. AbstractParameter, function value end, into ParameterHandling.jl.

What would be your preference? Maybe another suggestion?

willtebbutt commented 3 years ago

It would also be an option (composable with any of the above) to move some of the base definitions, e.g. AbstractParameter, function value end, into ParameterHandling.jl.

I'd rather not do this - I'm generally not a fan of defining stuff in the main source file (I generally try to minimise it).

I think I like something like option B the most. I like the idea of putting the api in one file, implementations for base types in another, and stuff for AbstractParameters in other files.