ADR Suggestion
New easyscience API structure, the Job structure.
#68
damskii9992
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
General
The Job API structure was first suggested in the context of EasyDiffraction (see easyscience/EasyDiffractionLib#96) as a means of providing a structured and reasonable API for the user. The API is how the user uses our software and it should be as simple as possible while being logical and easy to use.
The Job API structure is meant to be used across the technique-dependent libraries, and I here propose to use the same structure for the
easyscience
library.Current implementation
Currently, the
easyscience
API mimicslmfit
and is used as:Here, 'quad' is a
BaseObj
, i.e. a container of the fittingParameter
sa
,b
, andc
, similarly to theParameters
class fromlmfit
which also contains the parameters and passes them to the minimizer.The
math_model
is a function or other callable which uses the parameters and x-values to predict the y-values:This could also have been a class object with an implemented
__call__
dunder method. This differs slightly fromlmfit
where the model has to have the parameters as input (rather than reference them globally as ineasyscience
).In the more complicated technique-dependent libraries, the
math_model
is replaced with the external calculator (or rather, our wrapper around it), and the 'quad'BaseObj
is replaced with a hierarchy ofBaseObj
s which describes the theoretical system.Beta Was this translation helpful? Give feedback.
All reactions