GSoC 2026 – Calcium Interface for AA/QQbar

[Madhu Sripada]

Hello Travis,

My name is Madhu Sripada, and I'm a Computer Science majors with minors in AI/ML and have a strong interest in mathematical computing, numerical methods, and systems programming. I've worked primarily in C and Python, and have experience building performance-sensitive systems involving low-level libraries, numerical computation, and Python bindings, as well as working with game theory, especially in blockchains and oracles. I'm interested in the project on integrating Calcium's algebraic number fields into SageMath.

From my reading, the goal appears to be to expose FLINT/Calcium's qqbar_t and ca_t algebraic number implementations through Cython bindings and integrate them into Sage's parent/element framework to support AA and QQbar using Calcium as an alternative backend. This would require ensuring compatibility with Sage's coercion model and existing algebraic number infrastructure while enabling users to leverage Calcium's exact algebraic computations.

I've started looking through sage/rings/qqbar.py and the Calcium documentation to understand how the current implementation works and where the bindings would integrate. Before drafting a full proposal, I wanted to confirm whether this interpretation aligns with the intended direction, and whether the expectation would be to implement this as an optional backend rather than replacing the existing implementation.

I'd be grateful for your thoughts on a high-level approach - for example, starting with minimal Cython bindings for Calcium's algebraic number types before integrating them into Sage's parent/element framework. Also, are there any known challenges or past attempts I should be aware of when wrapping Calcium for Sage?

If there are specific parts of the codebase or preliminary issues you'd recommend exploring to get familiar with this area, I would really appreciate your guidance.

Regards
Madhu S

[Vincent Delecroix]

Dear Madhu,

Thanks for your interest in this project.

You are perfectly correct. Sage currently has its own implementation
of the field of algebraic numbers in sage/rings/qqbar.py. Note that
this file /contains the implementation of two parents: AA (for real
algebraic numbers) and QQbar (for complex algebraic numbers). The goal
is to have disjoint implementations of these two fields using flint as
a backend. The file sage/rings/qqbar.py should (mostly) stay as it
stands and you could consider adding something like
sage/rings/qqbar_flint.py. We suspect the flint backend to be much
more efficient than the current sage implementation. But this has to
be thoroughly tested. The question whether the global names AA/QQbar
should switch to the flint backend implementation is up to you in the
proposal.

I do not think there is any challenge with the coercion framework
since it works perfectly fine with AA/QQbar. Regarding this coercion
aspect, the only point will be to ensure compatibility with the
current AA/QQbar and the new one using flint.

For the high level approach, it is probably more efficient to
implement straight the new sage Parent/Element by looking at other
algebraic structures in sage that use flint as a backend (such as
matrices or polynomials). Though, nothing prevents you from doing
simpler Python binding to get familiar with flint code base.

One challenge is to get familiar with sage compilation and
development. In particular with AA/QQbar code base. You are encouraged
to look at open issues about sage algebraic numbers (some of them are
outdated though).

Best,
Vincent

> --
> You received this message because you are subscribed to the Google Groups "sage-gsoc" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-gsoc+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-gsoc/e13feaae-2cd9-4e2f-8252-52304e37bd1cn%40googlegroups.com.

[Madhu Sripada]

Hello Vincent & Travis, 

I’m excited to share that I have officially submitted my GSoC 2026 proposal, 'Integrating FLINT/Calcium Algebraic Number Fields as a Backend for SageMath's AA and QQbar.'

Based on our previous technical discussions and my audit of the qqbar.py implementation, my proposal focuses on delivering a disjoint sage/rings/qqbar_flint.py module. This architecture ensures we can leverage Calcium's high-performance qqbar_t and ca_t types while maintaining strict backward compatibility and seamless coercion with the existing infrastructure.

To demonstrate my readiness for the development cycle, I am currently preparing a diagnostic PR for src/sage/rings/qqbar.py. This PR will focus on improving doctest coverage for radical identities and verifying the consistency of the current ANRoot isolation logic—tasks that have directly informed my understanding of the performance bottlenecks I aim to solve.

I will follow up with the PR link as soon as it is open. I look forward to your feedback on the proposal and to contributing to SageMath's algebraic number infrastructure.

Regards, 

Madhu S

[Madhu Sripada]

"Hi Vincent and Travis,

Following up on my previous message, I have just opened the diagnostic PR for qqbar.py here: 
1.  Posted a technical investigation comment on Issue #30222: [https://github.com/sagemath/sage/issues/30222#issuecomment-4152123579]. 

2. Submitted a diagnostic PR: [src/sage/rings/qqbar.py: Add EXAMPLES block to ANBinaryExpr.exactify by Madhu18S · Pull Request #41932 · sagemath/sage].

I have also uploaded the final version of my proposal to the GSoC portal, which now includes the link to this contribution and my updated technical roadmap.  I would like to hear your feedback on these final updates if time permits before the window closes. Thank you for your guidance and support throughout this application period!

Regards
Madhu S