Skip to content

Determine general API structure for BMC for general applications #2

Description

@kylegodbey

We can use this issue to detail how we imagine interacting with our BMC framework in a general purpose way. Our existing implementation is very much hardcoded for mass tables, but I think it isn't too hard to come up with a general structure. This is sometimes called spec-driven development (nice writeup: https://medium.com/@ratherabstract/sdd-spec-driven-development-3556dacca165), and it essentially means we craft the specification and then use that as a guiding light for development.

To kick it off, we should break the implementation we have now into its core components:

  1. Set of models
  2. Valid on a given domain X
    2a. X can be a vector
  3. With a prediction Y3a. Y(X) can, in principle, be a vector itself (masses, radii, etc)
  4. Optional orthogonalization step
  5. Training, validation, and optional testing sets defined on a subset of X
    5a. It's also possible that we don't have a full Y(X) vector across each of these sets
  6. A training method that determines model weights given a training set
  7. A prediction method that, given a valid X vector, produces Y with the learned model weights

Am I missing something? Tagging @syiman as well for his insights

Metadata

Metadata

Assignees

Labels

documentationImprovements or additions to documentation

Type

Fields

No fields configured for Task.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions