icb-dcm / fiddy Goto Github PK

• split gradient check into gradient calculator and gradient checker
  • gradient calculator for applications requiring FD gradients
• gradient checker can stop calculating gradients for all sizes as soon as the check passes for any size
• parallelize
• refactor "check" functions and "postprocessor" functions to be more user-friendly (e.g. move into new Python file)
  • show examples of how to customize checks with e.g. functools.partial
• add argument option to output results to file

Add GHA action to deploy new releases to pypi

i.e. ensure gradients are computed correctly for points that e.g. exist on a 2D grid

At the moment, it's expected to be a class, that is then initialized with a function. Instead, we could expect some callable that accepts size/direction/point and returns the derivative.

Store each function call as a dataclass object, and the history would be a list of such objects.

Only support fiddy.function.Function so history can be automatically generated inside __call__.

Pros:

• can be used as a cache
  • either remove fiddy.function.CachedFunction, or disable history if CachedFunction is used
    • caching user option as a fiddy.function.Function attribute (e.g. boolean save_history and history_as_cache)
• can be easily converted to a human-readable format e.g. pandas DataFrame
  • and store/load history (cache) as a DataFrame
• easy to query results and reuse, if a DataFrame

Cons:

• speed
  • need to limit slow pandas operations such as append
  • may be slower than the current disk or ram caching (can support all caching options)

• fix crosslinks
• add docs to everything
• fix missing TYPE_OUTPUT and TYPE_FUNCTION (low priority)

• e.g. in gradient check, step size could be relative to expected gradient
• method to "move towards" best step size automatically
  • interpolation function
  • Newton's method

• add "getting start" page to RTD
• Jupyter notebook tutorials

• remove steps (only support directions and sizes, with helper function to construct)
• rename "dimension" to "direction" everywhere (i.e. directional derivative)
• possibly rename gradient to derivative (can do when higher-order derivatives are supported)

• allow users to run e.g. gradient checks with multiple methods (e.g. forward, backward, and central)
• store results such that e.g. comparison is easy (i.e. to see whether methods return consistent results, as a way to assess how trustworthy a FD result is for the problem)

• black
• flake8

In:

• precommit
• github actions