Adds limit(expr, v, a) syntax #39812

EigenVector22 · 2025-03-28T13:21:28Z

Implemented the limit(expr, variable, value) positional syntax to allow limits with respect to indexed variables or other variables not usable as keyword arguments.

Also, Updated the documentation and added doctests for the new syntax and associated error handling. Ensuring code coverage for the new argument parsing.

Fixes #38761 by allowing limits to be taken with respect to indexed variables like x[0] or other symbolic expressions not usable as keyword arguments.

While testing, the tests passed except the optional fricas ones that were failing before too.

📝 Checklist

The title is concise and informative.
The description explains in detail what this PR is about.
I have linked a relevant issue or discussion.
I have created tests covering the changes.
I have updated the documentation and checked the documentation preview.

⌛ Dependencies

Got the idea and direction of fixing the issue and the link to the relevant conversations in the given PR: #38780

EigenVector22 · 2025-03-28T13:24:58Z

Hello, @vincentmacri, @nbruin,

can you please review this and
suggest if any thing else needs to be done,

Thanks,

nbruin · 2025-03-28T16:00:13Z

src/sage/calculus/calculus.py

@@ -429,13 +429,16 @@
 from sage.misc.latex import latex
 from sage.misc.parser import Parser, LookupNameMaker
 from sage.structure.element import Expression
+from sage.symbolic.expression import Expression


Why this import? It shadows the one above. Figure out which one you need (why not the one that was already there?) and remove the other.

yes you right, the second import just overwrites the 1st one, made the necessary changes
Thanks,

sage.structure.element.Expression and sage.symbolic.expression.Expression aren't the same. Do you have a reason to change which one is imported here? There was probably a good reason why the code here originally imported the abstract base class rather than the concrete one.

This still needs addressing

okay, i guess i probably get this now, since the limit function is operating on symbolic expressions (converted via SR), so the abstract base class is probably sufficient, am i right?

src/sage/calculus/calculus.py

vincentmacri · 2025-03-28T20:45:34Z

I'll leave commenting on the code itself to @nbruin since he wrote the first draft of this.

All I'll add is that I find the usage of "new syntax" versus "old syntax" in the docstrings a bit confusing. It makes it sounds like we plan to deprecate the old syntax, which I don't think we do plan on doing (or should plan on doing unless there's a good reason).

I'm not sure what terms would be better. Maybe just show examples of both without referring to one as being new or old, and just mention in the examples why the syntax you're adding here is preferred/needed in some situations. For example, when I added additional functionality to the subs method for function field elements I made sure to have examples of the different syntax you could use. Given the motivation of this PR being to be able to compute limits where the x=a syntax doesn't work, I would explicitly say in the example for the limit(expr, v, a) syntax when you might prefer to use it. (In retrospect I think the same issue with x=a that you're fixing here applied to what I did there for the subs method, I didn't mention it in the example for the dictionary syntax there because it didn't occur to me that you might have indexed variables or something, although the dictionary syntax should support it.)

EigenVector22 · 2025-03-29T05:01:38Z

Hello Vincent,

Thanks for your feedback on the documentation. I also think that labeling the syntaxes as "new" and "old" maybe could imply we are deprecating x=a, which isn’t the case—both syntaxes are meant to stay supported, as of now unless( as you said) ......

I just wanted to ask that what should be next course of action ?
Should I update the docstrings to like remove the "new" and "old" labels and instead present both syntaxes side-by-side with examples. I will TRY to clarify like when each one of them is appropriate to use

I am thinking to include something like this in the docstrings:
Use limit(expr, x=a) for straightforward variable substitutions, but opt for limit(expr, v, a) when v is an indexed variable like y[1], since keyword arguments can’t directly handle indexed names.

Is this the right way of representation?

Thanks,

nbruin · 2025-03-29T06:46:36Z

I am thinking to include something like this in the docstrings: Use limit(expr, x=a) for straightforward variable substitutions, but opt for limit(expr, v, a) when v is an indexed variable like y[1], since keyword arguments can’t directly handle indexed names.

No, just be neutral:

There are two ways of invoking limit. One can write limit(expr, x=a, <keywords>) or limit(expr, x, a, <keywords>). In the first option, x must be a valid python identifier. Its string representation is used to create the corresponding symbolic variable with respect to which to take the limit. In the second option, x can simply be a symbolic variable. For symbolic variables that do not have a string representation that is a valid python identifier, for instance if x is an indexed symbolic variable, the second option is required.

EigenVector22 · 2025-03-29T09:33:06Z

I have made the necessary changes to the doctests and added examples where necessary, can you please review it.
Thanks,

EigenVector22 · 2025-03-29T17:07:03Z

@nbruin any other feedback regarding the code?

src/sage/calculus/calculus.py

nbruin · 2025-03-29T18:28:59Z

src/sage/calculus/calculus.py

+        is_getitem = hasattr(v.operator(), '__name__') and v.operator().__name__ == '__getitem__'
+        if not (is_getitem and v.operands()):
+            # If it’s not an indexed variable, checking if it’s numeric
+            if v.is_numeric():


certainly not necessary to further differentiate if you know you're going to raise an error

nbruin · 2025-03-29T18:30:04Z

src/sage/calculus/calculus.py

+        if not (is_getitem and v.operands()):
+            # If it’s not an indexed variable, checking if it’s numeric
+            if v.is_numeric():
+                raise TypeError(f"Limit variable must be a variable, not a constant number: {v}")


Just raise a more generic message here. You don't need to give the value that is causing the error. That's in the backtrace.

nbruin · 2025-03-29T18:30:49Z

src/sage/calculus/calculus.py

+        try:
+            a = SR(a)
+        except TypeError:
+            raise TypeError(f"Cannot convert limit point to symbolic ring: {a}")


just let SR(a) raise the error.

nbruin · 2025-03-29T18:33:03Z

src/sage/calculus/calculus.py

@@ -1498,38 +1699,53 @@ def mma_free_limit(expression, v, a, dir=None):

    EXAMPLES::


My expertise does not extend to mma_free_limit so I cannot review that code.

EigenVector22 · 2025-03-29T21:53:35Z

I've applied the suggested changes from the latest review.

Regarding the use of kwargv instead of argv: Initially, I intended to use kwargv since the documentation highlighted it as a
standard practice. However, I later opted for argv, my bad, should my discussed this beforehand
I also removed some unnecessary, bloated lines of code from the PR. I've been working on this for 2–3 weeks, and the build
broke a couple of times during that period. T_T

Everything has now been updated as suggested. Do you have any further feedback?

EigenVector22 · 2025-03-30T10:37:03Z

@vincentmacri any other feedback from your side ,?

nbruin

Please make sure you address all concerns. I think I have reflagged issues that I flagged before and that did not receive a response.

If you disagree with my assessment on any one of the items you can respond with your reasons and then we can take it from there.

src/sage/calculus/calculus.py

nbruin · 2025-03-30T21:37:12Z

src/sage/calculus/calculus.py

@@ -429,13 +429,16 @@
 from sage.misc.latex import latex
 from sage.misc.parser import Parser, LookupNameMaker
 from sage.structure.element import Expression
+from sage.symbolic.expression import Expression


This still needs addressing

src/sage/calculus/calculus.py

nbruin · 2025-03-30T21:41:22Z

src/sage/calculus/calculus.py

+
+    if len(args) == 2: # Syntax: limit(ex, v, a, ...)
+        if kwargs: # Cannot mix positional v, a with keyword args
+            raise ValueError(f"Use either limit(expr, v, a, ...) or limit(expr, v=a, ...) syntax. "


Error message should be an uncapitalized phrase describing the problem; not advice. So:

'''
Cannot mix positional specification of limit variable and point with keyword variable arguments
'''

No need for arguments in message: those can be obtained from traceback.

I don't think advice of the form Use either ... or ... is necessary here. Any advice would go after the primary error message.

nbruin · 2025-03-30T21:47:26Z

src/sage/calculus/calculus.py

+    elif len(args) == 0: # Potential syntax: limit(ex, v=a, ...) or limit(ex)
+        if len(kwargs) == 1: 
+            k, = kwargs.keys()
+            if not isinstance(k, str):


this test is not required:

sage: def f(*args,**kwargs): return args, kwargs sage: f(**{10:1}) TypeError: keywords must be strings

nbruin · 2025-03-30T21:47:55Z

src/sage/calculus/calculus.py

+            k, = kwargs.keys()
+            if not isinstance(k, str):
+                 raise ValueError(f"Invalid variable specification in keyword argument: {k} (must be a string)")
+            try:


no need to guard with try. Just let error propagate.

nbruin · 2025-03-30T21:48:35Z

src/sage/calculus/calculus.py

+
+    # Ensuring v is a symbolic expression
+    if not isinstance(v, Expression):
+        try:


no need to guard with "try". Just let it raise on error by itself

nbruin · 2025-03-30T21:50:20Z

src/sage/calculus/calculus.py

+    # Ensuring v is a symbolic expression
+    if not isinstance(v, Expression):
+        try:
+            v = SR(v)


create what you need: use

v=SR.symbol(v)

instead.

@nbruin
This approach is creating an Error:

For the call

limit(x^2 + 5, 5, 10):

v = 5 is an integer, not an instance of Expression

SR.symbol(v) is called with v = 5, but SR.symbol() expects a string to create a symbolic variable. Passing integer like 5 causes a

TypeError: expected string or bytes-like object, got 'sage.rings.integer.Integer'.

I think this error is occuring because the code assumes v can be converted to a symbolic variable directly, but a constant like 5 isn’t a valid limit variable, limits must be taken with respect to a variable (e.g., x), not a constant,

its working fine with this approach:

# Ensuring v is a symbolic expression and a valid limit variable if not isinstance(v, Expression): v = SR(v) if not v.is_symbol(): raise TypeError("limit variable must be a variable, not a constant")

nbruin · 2025-03-30T21:50:41Z

src/sage/calculus/calculus.py

-        v = var(k)
-        a = argv[k]
+    # Check if v is a valid limit variable
+    if not v.is_symbol() and v.is_constant():


you will have a symbol here with the change above, so no reason to check

EigenVector22 · 2025-03-31T15:53:33Z

@nbruin does everything looks good now?

nbruin

OK that looks fine now. I did find it painful in the review process to not have the comments and markings from the previous review available. Part of that might be github's interface. Another component is that you squash your commits in a forced push, destroying history. It might be better to just make successive commits. If you really want to squash before merge, you could squash at the very end to make a branch with a different (more concise) history but with the same effect on the tree.

src/sage/calculus/calculus.py

EigenVector22 · 2025-03-31T19:07:49Z

@nbruin , thanks so much for reviewing the PR thoroughly and providing detailed feedback.
I have tried to incorporate your feedback into my recent PRs.

Regarding the comment on squashing commits with a forced push: I initially thought that working alone on the branch wouldn't be an issue, but I see how it complicates code review. I'll adjust my approach and make successive commits going ahead

Thanks again!

EigenVector22 · 2025-04-01T17:54:35Z

hello, @roed314 can you review and run the workflows if possible,
Thanks,

roed314 · 2025-04-01T18:06:17Z

Done. It still looks like there's something strange going on with force pushes (if you look at the Files Changed you'll see a bunch of changes that are just 10.6 vs 10.6.rc1).

github-actions · 2025-04-01T20:14:59Z

Documentation preview for this PR (built with commit e74d80f; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

vincentmacri · 2025-04-01T21:45:34Z

src/sage/calculus/calculus.py

+    The positional `limit(expr, v, a)` syntax is particularly useful when
+    the limit variable `v` is an indexed variable or another expression
+    that cannot be used as a keyword argument (fixes :issue:`38761`)::


Suggested change

The positional `limit(expr, v, a)` syntax is particularly useful when

the limit variable `v` is an indexed variable or another expression

that cannot be used as a keyword argument (fixes :issue:`38761`)::

The positional ``limit(expr, v, a)`` syntax is particularly useful

when the limit variable ``v`` is an indexed variable or another

expression that cannot be used as a keyword argument

(fixes :issue:`38761`)::

When referring to code, typeset it with two ticks (code) rather than one tick (LaTeX).

You can see here how the formatting will look in the documentation: https://doc-pr-39812--sagemath.netlify.app/html/en/reference/calculus/sage/calculus/calculus#sage.calculus.calculus.limit

vincentmacri

Minor formatting fix

nbruin · 2025-04-02T17:13:08Z

src/sage/calculus/calculus.py

+            return SR(l)
+        except TypeError:
+            return l
+


Why the "try" guard and the alternatives? Do you have any examples where l cannot be coerced into ex.parent() but it can be coerced into SR?
Do you have any examples where l cannot be coerced into SR but the return value is still interesting?

Note that raising an error is often better than returning anomalous output, so you should really only guard like this if you're positive that this leads to concretely better output.

In the original code, the return line was just

return ex.parent()(l)

and no issue was raised about that and the stated goal of this PR doesn't mention changing the way that limit returns its value either. I think you need a good reason to change how it returns its value.

i think the i by mistake deleted the reply i posted to this yesterday,

basically, the added the second fallback after the SR(), was due to being speculative for FURTHER errors, so as a safety net I added l, but yes, on a comparative if we see, letting the error surface after SR() FAILS would be a better choice, at least we'll get some info about it,
made the changes

nbruin · 2025-04-03T18:52:55Z

src/sage/calculus/calculus.py

+    try:
+        return original_parent(l)
+    except (TypeError, ValueError):
+        return SR(l) 


A bit better already but why the try/except? Do you have an example where original_parent(l) fails and SR(l) succeeds? I don't think you gain anything with this complication of the original code.
I already asked you this in the previous review but you didn't provide an answer or removed the complication of the code.

i think there is a very example for this, consider limit(f, x=0) where f(x) = sin(1/x) the result l=ind as x approaches 0, original_parent(l) will raise a TypError, except block catches this TypeError and executes SR(l), which is SR(ind), i think this example is sufficient to show the necessity of try and except, and i don't think they bring in complexity of any sorts, it equips us better to handle such cases,

Did you try? As far as I can see, ind is a completely valid value to be coerced into a "callable function ring":

sage: f(x)=sin(1/x) sage: ind = limit(f(x),x=0); ind ind sage: parent(f)(ind) x |--> ind

So I don't think the "except" clause will ever be triggered when return SR(l) would succeed.
(Whether the answer is a useful one is a different question, but that leads to design decisions that need to be considered separately)

ok, i just ran it locally, it does pass!, i was arguing on my wrong premise, apologies,

should i make the change and finally remove return SR(l)?,

Yes, I don't think there is any reason to change that line from what it originally was.

cool, i'll revert to the original version

EigenVector22 · 2025-04-03T21:41:42Z

Made the FINAL changes

EigenVector22 · 2025-04-03T21:54:48Z

@roed314 if possible can you run the CIs for this PR?
Thanks,

nbruin · 2025-04-04T16:50:18Z

Looks like the tests did run but failed. It doesn't look like the failure is connected to the changes made on this ticket. Hopefully this gets fixed soon (or otherwise clarified) so that this PR can be properly tested.

EigenVector22 · 2025-04-04T18:12:22Z

Yup, you are right, the failures aren't connected to any changes made on this ticket, these failures also came while testing locally, they are linked to fricas and giac packages,
Whom should i contact regarding these failures? if you could suggest,
Thanks

vincentmacri

This should fix the failing linter check.

src/sage/calculus/calculus.py

Co-authored-by: Vincent Macri <[email protected]>

EigenVector22 · 2025-04-04T20:54:08Z

Committed the suggestions for the above changes @vincentmacri, could you also guide a bit about these fricas and giac failures

vincentmacri · 2025-04-07T16:59:45Z

@vincentmacri, could you also guide a bit about these fricas and giac failures

Sorry, but I have no clue about that. I don't know too much about Sage's interaction with external libraries. Do those tests pass on your machine?

EigenVector22 · 2025-04-08T15:35:22Z

No, I tested them on my develop branch as well and they still failed there, on the issue branch these were actually the only tests that were still failing everything else had passed

vincentmacri · 2025-04-09T18:37:52Z

@dimpase I've seen you do some work on maintaining the external libraries. Do you have any idea what might be happening here?

dimpase · 2025-04-09T18:55:03Z

fricas failures might be due to a too old version of fricas installed on the box. We don't enforce it, but there is a ready to be merged #39796 doing this.

giac - no idea. giac is a backet case IMHO.

nbruin · 2025-04-09T19:14:25Z

I think I have seen CI tests on other PRs succeeding recently when tests on this one were failing for fricas and giac. That would indicate that there might be something on this PR that is problematic. I don't recall seeing anything that pointed to a possible interaction, but I think we do need to make certain that any failures found on this PR are also happening on baseline. It's a little annoying that there only seems to be easy access to the latest CI results (which are waiting for approval at the moment). Seeing the history of success/failure of tests on this PR would be very helpful in assessing how likely it is that these problems are just due to infrastructure.

dimpase · 2025-04-11T06:54:03Z

I think I have seen CI tests on other PRs succeeding recently when tests on this one were failing for fricas and giac. That would indicate that there might be something on this PR that is problematic. I don't recall seeing anything that pointed to a possible interaction, but I think we do need to make certain that any failures found on this PR are also happening on baseline. It's a little annoying that there only seems to be easy access to the latest CI results (which are waiting for approval at the moment). Seeing the history of success/failure of tests on this PR would be very helpful in assessing how likely it is that these problems are just due to infrastructure.

We are seeing warnings regarding os.fork() etc. use on Python 3.12+, related to fricas calls, which come from python/cpython#100229. See e.g. #39796

These are indicating potential problems with pexpect interfaces, I guess.

EigenVector22 · 2025-04-12T17:01:36Z

These are indicating potential problems with pexpect interfaces, I guess.

just wanted to ask, what exactly are the role of the interfaces mentioned?, and what can we do to tackle this problem, thanks

dimpase · 2025-04-12T17:10:57Z

pexpect interfaces, in src/sage/interfaces/, are for exchanging data with external executables, e.g. fricas, without the need to create temporary files.

EigenVector22 · 2025-04-12T17:35:58Z

Thanks

EigenVector22 · 2025-04-20T15:10:12Z

Hello, what are the next steps to take to progress on this PR, anything that i have to do, or now does it relies only on the pexpect interfaces?
Thanks

dimpase

does this trigger CI?

EigenVector22 · 2025-04-20T15:30:29Z

nope,

vincentmacri · 2025-04-22T21:50:55Z

@roed314 would you mind approving the workflow run again?

dimpase · 2025-04-23T14:38:41Z

@roed314 - I am in the core team of sagemath (which has mostly people not active any more, by the way), why can't I approve CI runs?

github-actions bot added the s: needs review label Mar 28, 2025

nbruin reviewed Mar 28, 2025

View reviewed changes

src/sage/calculus/calculus.py Outdated Show resolved Hide resolved

EigenVector22 force-pushed the fix-limit-syntax-38761 branch from 28b5916 to f468ab1 Compare March 28, 2025 16:22

EigenVector22 force-pushed the fix-limit-syntax-38761 branch 2 times, most recently from 05b3f07 to e806bf7 Compare March 29, 2025 09:30

nbruin reviewed Mar 29, 2025

View reviewed changes

src/sage/calculus/calculus.py Outdated Show resolved Hide resolved

nbruin suggested changes Mar 29, 2025

View reviewed changes

EigenVector22 force-pushed the fix-limit-syntax-38761 branch from e806bf7 to 40a04c1 Compare March 29, 2025 21:41

EigenVector22 requested a review from nbruin March 29, 2025 22:43

nbruin suggested changes Mar 30, 2025

View reviewed changes

EigenVector22 force-pushed the fix-limit-syntax-38761 branch from 40a04c1 to 8858361 Compare March 31, 2025 02:27

nbruin approved these changes Mar 31, 2025

View reviewed changes

src/sage/calculus/calculus.py Show resolved Hide resolved

vbraun force-pushed the develop branch from 8a8453f to b8f98e7 Compare March 31, 2025 22:55

EigenVector22 force-pushed the fix-limit-syntax-38761 branch from 8858361 to e74d80f Compare April 1, 2025 17:49

vincentmacri reviewed Apr 1, 2025

View reviewed changes

vincentmacri suggested changes Apr 1, 2025

View reviewed changes

Fix: Restored limit return type for callable functions

c3784e2

nbruin reviewed Apr 2, 2025

View reviewed changes

Fix SyntaxError in limit return logic

72aef14

EigenVector22 requested a review from nbruin April 3, 2025 18:42

nbruin reviewed Apr 3, 2025

View reviewed changes

Revert to simpler limit return logic per review

ae23624

Merge branch 'develop' into fix-limit-syntax-38761

5568648

vincentmacri suggested changes Apr 4, 2025

View reviewed changes

src/sage/calculus/calculus.py Outdated Show resolved Hide resolved

src/sage/calculus/calculus.py Outdated Show resolved Hide resolved

EigenVector22 and others added 2 commits April 5, 2025 02:21

Update src/sage/calculus/calculus.py

d9ac231

Co-authored-by: Vincent Macri <[email protected]>

Update src/sage/calculus/calculus.py

48ef5c0

Co-authored-by: Vincent Macri <[email protected]>

dimpase approved these changes Apr 20, 2025

View reviewed changes

Merge branch 'develop' into fix-limit-syntax-38761

bc0ac03

		@@ -1498,38 +1699,53 @@ def mma_free_limit(expression, v, a, dir=None):

		EXAMPLES::

Adds limit(expr, v, a) syntax #39812

Are you sure you want to change the base?

Adds limit(expr, v, a) syntax #39812

Conversation

EigenVector22 commented Mar 28, 2025

📝 Checklist

⌛ Dependencies

EigenVector22 commented Mar 28, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vincentmacri commented Mar 28, 2025

EigenVector22 commented Mar 29, 2025

nbruin commented Mar 29, 2025

EigenVector22 commented Mar 29, 2025

EigenVector22 commented Mar 29, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EigenVector22 commented Mar 29, 2025

EigenVector22 commented Mar 30, 2025

nbruin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EigenVector22 commented Mar 31, 2025

nbruin left a comment

Choose a reason for hiding this comment

EigenVector22 commented Mar 31, 2025

EigenVector22 commented Apr 1, 2025

roed314 commented Apr 1, 2025

github-actions bot commented Apr 1, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vincentmacri left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EigenVector22 Apr 3, 2025 • edited Loading

Choose a reason for hiding this comment

nbruin Apr 3, 2025 • edited Loading

Choose a reason for hiding this comment

EigenVector22 Apr 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EigenVector22 commented Apr 3, 2025

EigenVector22 commented Apr 3, 2025

nbruin commented Apr 4, 2025

EigenVector22 commented Apr 4, 2025

vincentmacri left a comment

Choose a reason for hiding this comment

EigenVector22 commented Apr 4, 2025

vincentmacri commented Apr 7, 2025

EigenVector22 commented Apr 8, 2025

vincentmacri commented Apr 9, 2025

dimpase commented Apr 9, 2025 • edited Loading

nbruin commented Apr 9, 2025

dimpase commented Apr 11, 2025

EigenVector22 commented Apr 12, 2025 • edited Loading

dimpase commented Apr 12, 2025

EigenVector22 commented Apr 12, 2025

EigenVector22 commented Apr 20, 2025 • edited Loading

dimpase left a comment

Choose a reason for hiding this comment

EigenVector22 commented Apr 20, 2025 • edited Loading

vincentmacri commented Apr 22, 2025

dimpase commented Apr 23, 2025

EigenVector22 Apr 3, 2025 •

edited

Loading

nbruin Apr 3, 2025 •

edited

Loading

EigenVector22 Apr 3, 2025 •

edited

Loading

dimpase commented Apr 9, 2025 •

edited

Loading

EigenVector22 commented Apr 12, 2025 •

edited

Loading

EigenVector22 commented Apr 20, 2025 •

edited

Loading

EigenVector22 commented Apr 20, 2025 •

edited

Loading