Make critical point computation interruptible and configurable - #63
Make critical point computation interruptible and configurable#63johndcobb wants to merge 5 commits into
Conversation
Introduce configurable start-solution expansion and interrupt handling. Added StartSolutionExpansionResult type and iterator helpers; added flags expand_start_solutions, expand_start_solutions_newton, expand_start_solutions_gradient_flow and catch_interrupt to critical_points/_expand_start_solutions/_solve_and_trace to allow selective expansion and safe interruption. Improve robustness by catching interrupt exceptions during Newton and gradient-flow phases and returning partial results when appropriate. Wrap graph connection loops with interrupt-aware try/catch and add catch_interrupt arg. Update tests to exercise new expansion options and adjust Project.toml extras/targets for testing.
Add a dedicated docs workflow and documentation source to build and deploy the site automatically (docs/Project.toml, docs/make.jl, docs/src assets and index). Update CI workflow (.github/workflows/ci.yml) to run on pushes to main, include PR-aware concurrency grouping, and use --color=yes + Pkg.test() for running tests. Update Project.toml to remove the unused Pkg extra/target. Ignore built docs in .gitignore. Also include assorted changes to examples, src (gradient_cache, hypersurfaces, pseudo_witness_sets) and tests to accompany these updates.
Rename `ProjectedHypersurfaceRegions.jl` to `ProjectedHypersurfaces.jl` throughout the project. Add sampling, interpolation, and irreducible decomposition workflows; introduce structured routing and partition results with interrupt-safe partial results and status codes; and update documentation, examples, tests, plotting, and generated quadratic artifacts for the new APIs.
| expand_start_solutions = true, | ||
| expand_start_solutions_newton = true, | ||
| expand_start_solutions_gradient_flow = true, |
There was a problem hiding this comment.
For simplicity (and to avoid the possibility of the user making inconsistent calls), perhaps it's enough to have the keywords expand_start_solutions_newton and expand_start_solutions_gradient_flow (and then simply use expand_start_solutions_newton || expand_start_solutions_gradient_flow instead of expand_start_solutions)?
| start_grid_width = 5, | ||
| start_grid_stepsize = 0.2, |
There was a problem hiding this comment.
Only indirectly related to the goal of the PR, but perhaps we should keep the grid size smaller, to avoid the preliminary computation of start solutions taking too long (which isn't great for demonstration purposes). Alternatively, or additionally, one could consider setting the deffault of expand_start_solutions_newton to false, since this usually doesn't give a lot extra start solutions in my experience.
Written primarily with codex, but I've looked through it. All tests pass. Addresses #59.
expand_start_solutions
expand_start_solutions_newton
expand_start_solutions_gradient_flow
catch_interrupt (matches homotopy continuation flag)