Add ExtendedGCD builtin by rocky · Pull Request #2076 · Mathics3/mathics-core

rocky · 2026-10-29T16:47:38Z

Add a first cut at ExtendedGCD.
Go over the divlike docs.

Todo: extend to polynomials like PolynomialGCD, etc.

Start to revise to more modern Python conventions via ruff.

Corrected typos in docstrings and comments for clarity.

…to add-ExtendedGCD

tombouctou

Review of the ExtendedGCD addition. The first two inline comments are about wrong results and a crash, which I confirmed by running the PR branch and comparing with WMA 15. The rest are smaller: docs links, type hints, and a formatting bug in Expression.__repr__/__str__.

tombouctou · 2026-10-30T08:46:31Z

+    https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm</url> (<url>
+    :SymPy:https://docs.sympy.org/latest/modules/polys/domainsref.html#sympy.polys.domains.IntegerRing.gcdex</url>, <url>
+    :WMA:
+    https://reference.wolfram.com/language/ref/GCD.html</url>)


This link points to GCD.html; it should be ExtendedGCD.html.

tombouctou · 2026-10-30T08:46:31Z

-    https://reference.wolfram.com/language/ref/GCD.html</url>
+    <url>:Greatest common divisor:
+    https://en.wikipedia.org/wiki/Greatest_common_divisor</url> (<url>
+    :SymPy:https://docs.sympy.org/latest/modules/polys/domainsref.html#sympy.polys.domains.IntegerRing.gcdex</url>, <url>


This SymPy link is for GCD, but it points to IntegerRing.gcdex (the extended GCD) rather than gcd.

tombouctou · 2026-10-30T08:46:31Z

    <url>:Modular exponentiation:
-    https://en.wikipedia.org/wiki/Modular_exponentiation</url> SymPy: <url>:mod_inverse:https://docs.sympy.org/latest/modules/core.html#sympy.core.numbers.mod_inverse</url>, <url>
+    https://en.wikipedia.org/wiki/Modular_exponentiation</url> (<url>:SymPy:
+    :mod_inverse:https://docs.sympy.org/latest/modules/core.html#sympy.core.numbers.mod_inverse</url>, <url>


This <url> has two labels, :SymPy: and :mod_inverse:, so the renderer takes :SymPy: as the label and :mod_inverse:https://… as the target, which gives a broken link.

tombouctou · 2026-10-30T08:46:31Z

@@ -1,29 +1,66 @@
-"""
+b"""


b""" makes this a bytes literal, not a docstring, so the module's __doc__ is None. It looks like a stray keystroke.

Actually, yes, "b" is a glitch on my keyboard (which is rather old, and the printed letters have worn off). Usually, there is a string of b's, and I try to catch those.

tombouctou · 2026-10-30T08:46:31Z



-def eval_GCD(ns: tuple) -> Optional[Integer]:
+def eval_ExtendedGCD(arguments: tuple | Integer) -> Integer | None:


The return annotation says Integer | None, but the function returns a ListExpression. Also, gcdex_list's -> (list, int) is a tuple expression rather than a type hint; tuple[list[int], int] would be.

On line 49: with a single negative argument, ExtendedGCD[-5] gives {-5, {1}}, while WMA gives {5, {-1}}. The len(numbers) == 1 branch of gcdex_list has the same problem.

tombouctou · 2026-10-30T08:46:31Z

+    if isinstance(arguments, Integer):
+        return ListExpression(arguments, ListExpression(Integer1))
+    integers: list[int] = []
+    for element in arguments.elements:


With a single argument that is not an Integer, arguments is the atom itself, which has no .elements. ExtendedGCD[x] and ExtendedGCD[2.5] raise AttributeError: … has no attribute 'elements' out of the evaluator. WMA leaves ExtendedGCD[x] unevaluated.

A check was added in mathics/buiiltin/divlike.py.

The reason it was not added here is that the general philosophy is that general argument checking is done in the Builtin class. That way, evaluation functions work a little faster. If there is ever compilation, these eval functions will make up bytecode instructions.

That makes sense, thanks for explaining. Keeping the eval functions free of argument checks, so they stay fast and could someday be compiled, is a good reason. ExtendedGCD[x] and ExtendedGCD[2.5] now stay unevaluated, as in WMA. One small difference: WMA also gives ExtendedGCD::exact: Argument 2.5 in ExtendedGCD[2.5] is not an exact number. for the inexact case.

tombouctou · 2026-10-30T08:46:31Z

    def __repr__(self) -> str:
-        return "<Expression: %s[%s]>" % (
-            repr(self.head),
+        return f"<Expression: {self.head!r}[%s]>" % (


This mixes an f-string with %-formatting, so the text of self.head!r is itself treated as a format string. A head containing % breaks it: repr(Expression(String("50%"), Integer(1))) raises ValueError: unsupported format character, and %s in a head raises "not enough arguments". __str__ has the same problem. Interpolating the elements in the same f-string avoids it.

In the next commit, I'll revert this change since I am not confident how to fix.

Here is a fix that keeps everything in one f-string, so nothing from the head or the elements is read as a format spec:

def __repr__(self) -> str: elements = ", ".join(repr(element) for element in self.elements) return f"<Expression: {self.head!r}[{elements}]>" def __str__(self) -> str: elements = ", ".join(str(element) for element in self.elements) return f"{self.head}[{elements}]"

The revert brought __repr__ back to master's %-formatting, which was safe because the % applied to the whole template. __str__ in the PR still has f"{self.head}[%s]" % (...), so str(Expression(String("50%"), Integer(1))) still raises ValueError. Either the f-string version above or master's "%s[%s]" % (str(self.head), ...) fixes it.

tombouctou · 2026-10-30T08:46:31Z

                   in Monomial's __cmp() for the reverse ordering when
                   comparing symbols in the monomial.
        """
+        exps: dict[tuple[str, str], float | complex] = {}


This dict is overwritten by exps, coefficient = monomial before it is used. _build_element_order is on a hot path (canonical ordering), so this allocates a dict on every call for nothing. A bare annotation, exps: dict[...], would keep the type without the allocation.

Co-authored-by: tombouctou <vissi@vissi.su>

rocky · 2026-10-30T09:56:04Z

@tombouctou: Thanks for the very detailed review. I think I addressed everything, but I still make a lot of mistakes. (That's why I've worked so much on debuggers.)

Feel free to suggest more changes though, or suggest a fix for the change I don't feel confient in addressing.

tombouctou · 2026-10-30T10:10:21Z

@rocky Thank you for going through every comment in such detail, and for explaining the reasoning where you chose differently: checking arguments in the Builtin class and keeping the eval functions lean is a good principle, and I'll keep it in mind in my own PRs.

I re-ran the PR head (703897b) against WMA 15. ExtendedGCD[3, 2], ExtendedGCD[12, 8, 6], ExtendedGCD[-4, 6] and the non-integer arguments now all agree. Two single-argument cases still differ:

	PR	WMA
`ExtendedGCD[-5]`	`{-5, {-1}}`	`{5, {-1}}`
`ExtendedGCD[0]`	`{0, {-1}}`	`{0, {0}}`

The GCD should be the absolute value, with the sign moved into the coefficient, and for 0 the coefficient is 0. For example:

    if isinstance(arguments, Integer):
        n = arguments.value
        return ListExpression(Integer(abs(n)), ListExpression(Integer((n > 0) - (n < 0))))

In the __repr__ thread I left a fix for the formatting issue. __str__ in the PR still has the f-string/% mix.

rocky added 2 commits October 29, 2026 12:29

Add Extended GCD.

5db7aab

Go over divlike docs

57bfb82

rocky force-pushed the add-ExtendedGCD branch from 36debd9 to 57bfb82 Compare October 29, 2026 16:51

rocky changed the title ~~Add extended gcd~~ Add ExtendedGCD builtin Oct 29, 2026

rocky and others added 7 commits October 29, 2026 17:06

Merge branch 'master' into add-ExtendedGCD

9a4e432

Fix typos in comments for clarity

f92297a

Fix typos in divlike.py documentation

30517d7

Corrected typos in docstrings and comments for clarity.

Fix typo in gcdex_list docstring

6d9e969

run ruff over changed files

ab85767

Merge branch 'add-ExtendedGCD' of github.com:Mathics3/mathics-core in…

8f09359

…to add-ExtendedGCD

isort and black

180656b

rocky requested review from mmatera and tombouctou October 30, 2026 00:16

tombouctou reviewed Oct 30, 2026

View reviewed changes

rocky and others added 4 commits October 30, 2026 05:05

Update mathics/builtin/intfns/divlike.py

48076f3

Co-authored-by: tombouctou <vissi@vissi.su>

Try to address @tombouctou execellent review

069fede

One more link correction

c6e77f3

revert Expression.__repr__ change since I am not confident how to fix

703897b

rocky and others added 3 commits October 30, 2026 06:45

More corrections from tombouctou

6846d3a

Merge branch 'master' into add-ExtendedGCD

e8dce4c

Merge branch 'master' into add-ExtendedGCD

dcbfdf2

rocky merged commit ce535a6 into master Oct 31, 2026
15 checks passed

rocky deleted the add-ExtendedGCD branch October 31, 2026 14:18



		def eval_GCD(ns: tuple) -> Optional[Integer]:
		def eval_ExtendedGCD(arguments: tuple \| Integer) -> Integer \| None:

Conversation

rocky commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tombouctou left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rocky commented Oct 30, 2026

Uh oh!

tombouctou commented Oct 30, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

rocky commented Oct 29, 2026 •

edited

Loading