MatthewPeterKelly / MatthewPeterKelly/fractal-renderer
Generalize ODE solver
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 6
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
The ODE solver currently has two problems:
- it hard-codes the dynamics function
- it hard-codes the dimension of the state vector
This makes it tricky to experiment with things like, for example, adding an extra state to track angular distance travelled, or adding an extra parameter to the dynamics function.
I think that the rough design approach here would be to make a structure that holds the ODE solver cache data, which would allow us to avoid allocating new memory on each solver step. Then another utility function or class to actually use that ODE step solver to generate a complete simulation.
Rather than hard-coding the dynamics function, use rust's built-in features for high-performance lambda functions and a proper trait interface.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files or tests are named, so first locate the current ODE solver and inspect how its dynamics function, state dimension, and per-step allocations are handled. Read the surrounding fractal simulation entry points before choosing the cache and simulation interfaces. Done means the solver supports varying state dimensions and dynamics callbacks through a Rust trait or closure interface without allocating on each step.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- computer-graphics
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100