Let's generalize the generator to take and return documents, and then implement the IO specific to this library outside of that and in pipelines.
[x] Equations have plaintext forms representing the LaTeX, SymPy, and Python functional Forms, conducive to generating documentation, symbolic modules, and numeric modules, respectively.
[x] Forms are representations of Equations or Params, and in this work are invariant in the number of forms, those forms being latex, sympy, and python, the allowable FormKinds. It may be desirable to represent forms in a more generic fashion in the future, but for now we can assume there is enough flexibility in Forms to build complex representations of equations. For instance, two Equations may have similar Forms, with the same latexForm, but different pythonForms.
[x] A Param specifies the symbols, variables, or functional parameters of Equations. These also have Forms.
[x] Forms have a transform method, which applies a sequence of Transforms in order, returning a copy of itself with those transforms applied
[x] A Transform consists of src and dstFormKinds, and a set of repls, simple string replacements to be applied to produce a dstFormKind value from the srcFormKind value. The src and dstFormKind may be the same. Consider also regex transforms.
[x] An Implementation consists of src and dstFormKinds, and a callable with signature (FormKind, FormKind) -> Any. When the value of a form is an empty string, the "" sentinel value, then an Implementation should exist that can produce that form from another form which is not empty. This permits complex derivations of one form from another, like a python form produced by evaluating and solving the sympy form for a particular variable
Tasks
[ ] Isolate IO to boilercv_pipeline.correlations
Motivation and context
Test plan
Checklist
[x] My code follows this project's code style.
[x] My change requires a change to the documentation.
Description
Let's generalize the generator to take and return documents, and then implement the IO specific to this library outside of that and in pipelines.
Equation
s have plaintext forms representing the LaTeX, SymPy, and Python functionalForms
, conducive to generating documentation, symbolic modules, and numeric modules, respectively.Forms
are representations ofEquation
s orParam
s, and in this work are invariant in the number of forms, those forms beinglatex
,sympy
, andpython
, the allowableFormKind
s. It may be desirable to represent forms in a more generic fashion in the future, but for now we can assume there is enough flexibility inForms
to build complex representations of equations. For instance, twoEquation
s may have similarForm
s, with the samelatex
Form
, but differentpython
Form
s.Param
specifies the symbols, variables, or functional parameters ofEquation
s. These also haveForm
s.Forms
have atransform
method, which applies a sequence ofTransform
s in order, returning a copy of itself with those transforms appliedATransform
consists ofsrc
anddst
FormKind
s, and a set ofrepls
, simple string replacements to be applied to produce adst
FormKind
value from thesrc
FormKind
value. Thesrc
anddst
FormKind
may be the same. Consider also regex transforms.AnImplementation
consists ofsrc
anddst
FormKind
s, and a callable with signature(FormKind, FormKind) -> Any
. When the value of a form is an empty string, the""
sentinel value, then anImplementation
should exist that can produce that form from another form which is not empty. This permits complex derivations of one form from another, like apython
form produced by evaluating and solving thesympy
form for a particular variableTasks
boilercv_pipeline.correlations
Motivation and context
Test plan
Checklist
Terms