GSoC 2026: Discussion on efficient Jacobian/Hessian evaluation for optimization and ODE integration project

[XH W]

Hello SymPy community,

I am preparing a GSoC proposal for the project “Code Generation: Efficient Jacobian and Hessian Evaluation for Optimization and ODE Integration” from the ideas page, and I would really appreciate feedback on whether my current direction is reasonable.

I have been studying the previous work around this idea, especially the earlier PR #25801, the PR #26773 (_forward_jacobian), and the mailing-list discussion from last year about Jacobian/Hessian code generation for ODE/optimization.

My current understanding is:

1. forward_jacobian already provides a faster Jacobian construction path for large systems, but it is still an internal building block rather than a complete user-facing codegen pipeline.
2. The larger remaining gap seems to be integrating this kind of derivative computation with lambdify / codegen workflows in a way that avoids unnecessary expansion and repeated work.
3. For this project, it probably makes more sense to solve the dense Jacobian/Hessian workflow first before thinking about sparse structure or larger backend changes.

Based on that, my current proposal idea is roughly:

1. Build on the work from #26773 and extend the CSE-based derivative workflow from first derivatives to second derivatives, so that Hessians can also be constructed from the CSE representation.
2. Provide SciPy-friendly numerical outputs for optimization and ODE workflows, i.e. functions that return Jacobians/Hessians in ndarray-compatible form.
3. Investigate whether a symjit-style execution backend could be used after the symbolic/CSE derivative planning stage to accelerate numerical evaluation. 

I am currently thinking of this as an optional backend direction rather than the core deliverable.

My main questions are:

1. Does this overall scope sound reasonable, or should I narrow the proposal further and focus first on the dense Jacobian + codegen/lambdify path?
2. Is extending the CSE-based workflow from Jacobian to Hessian the right architectural direction, or would maintainers prefer a different approach?
3. Is it reasonable to build this proposal around cse(), or are there important limitations / edge cases that I should explicitly account for?

Thank you very much for your time and feedback.

Evan

[Jason Moore]

Hi Evan,

This looks sound.

> 3. For this project, it probably makes more sense to solve the dense Jacobian/Hessian workflow first before thinking about sparse structure or larger backend changes.

I'm not sure what you are meaning by this.

> 3. Investigate whether a symjit-style execution backend could be used after the symbolic/CSE derivative planning stage to accelerate numerical evaluation.

Symjit does cse internally. We should make symjit a general backend to lambdify as a first step to incorporating it into SymPy.

> 1. Does this overall scope sound reasonable, or should I narrow the proposal further and focus first on the dense Jacobian + codegen/lambdify path?

Creating a function that makes scipy style functions for their various solvers is sufficiently large in scope.

> 2. Is extending the CSE-based workflow from Jacobian to Hessian the right architectural direction, or would maintainers prefer a different approach?

We should build on prior work, in general.

> 3. Is it reasonable to build this proposal around cse(), or are there important limitations / edge cases that I should explicitly account for?

cse() is used in both lambdify() and forward_jacobian, so I don't think you will have to worry about this in detail. It is already available. If you end up creating a symbolic function that generates the Hessian based on the forward jacobian code, then maybe you will have to directly interact with cse.

Jason

Jason

moorepants.info
+01 530-601-9791

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sympy/f4cab445-2f0b-4221-8354-a22b9e8e3f98n%40googlegroups.com.

[Evan]

Hi Jason,

Thank you for your feedback! 

> 3. For this project, it probably makes more sense to solve the dense Jacobian/Hessian workflow first before thinking about sparse structure or larger backend changes.

What I meant was mainly about project priority. My current understanding is that the first step should be to make the Jacobian/Hessian generation and the SciPy-style API work well, and then consider symjit separately as an execution/backend direction.

>Symjit does cse internally. We should make symjit a general backend to lambdify as a first step to incorporating it into SymPy.

Since lambdify does not currently have a built-in symjit backend, I am wondering whether it would be better to first work on integrating symjit into lambdify as a new backend (so it can be used directly through the existing lambdify interface), or instead use symjit mainly as a reference and design a new JIT approach from scratch within this proposal.

Evan

[Jason Moore]

You don't need symjit for this particular project at all. Symjit and the solution for function/jacobian/hessian should be separate.

Jason

moorepants.info
+01 530-601-9791

To view this discussion visit https://groups.google.com/d/msgid/sympy/d47237c8-896b-4930-897a-16b7953a1507n%40googlegroups.com.