limit(floor(0.1+0.1*sin(1/x)),x=0) should return 0 and not ind

[AdityaK1729]

Steps To Reproduce

sage: f=floor(0.1+0.1*sin(1/x))
sage: limit(f,x=0)

or directly,

sage: limit(floor(0.1+0.1*sin(1/x)),x=0)

Expected Behavior

0

Actual Behavior

ind

Additional Information

No response

Environment

• OS: WSL2 on Windows 11
• Sage Version: 10.6rc0

Checklist

• I have searched the existing issues for a bug report that matches the one I want to file, without success.
• I have read the documentation and troubleshoot guide

[edoarad]

The result is ind also for limit(floor(0.5 + 0.2*sin(1/x)),x=0).

Also, limit(min(1, sin(1/x)),x=0) returns 1.

[EigenVector22]

According to me ,
We need to understand, Sage's limit function uses the Maxima backend by default. Maxima often returns ind (meaning "indefinite but bounded") precisely for cases like this, where the function oscillates between finite bounds near the limit point without converging to a single value.

So, while the expectation might be 0 , Maxima's result ind accurately reflects the fact that the standard two-sided limit does not exist due to the oscillation.

What does this means is behavior is likely not a bug in the Sage limit wrapper code (like the argument parsing code ), but rather the mathematically expected result from the backend (Maxima) for a non-existent limit of this type.

Again, this is what i suspect is the case here, the maintainers could confirm,
Thanks,

some references that you can refer to:

https://www.scotchildress.com/wxmaxima/Limits/Limits.html

https://maxima.sourceforge.io/docs/manual/maxima_99.html

[AdityaK1729]

According to me , We need to understand, Sage's limit function uses the Maxima backend by default. Maxima often returns ind (meaning "indefinite but bounded") precisely for cases like this, where the function oscillates between finite bounds near the limit point without converging to a single value.

So, while the expectation might be 0 , Maxima's result ind accurately reflects the fact that the standard two-sided limit does not exist due to the oscillation.

What does this means is behavior is likely not a bug in the Sage limit wrapper code (like the argument parsing code ), but rather the mathematically expected result from the backend (Maxima) for a non-existent limit of this type.

Again, this is what i suspect is the case here, the maintainers could confirm, Thanks,

some references that you can refer to:

https://www.scotchildress.com/wxmaxima/Limits/Limits.html

https://maxima.sourceforge.io/docs/manual/maxima_99.html

the standard 2 sided limit does exist, just plot the function, its 0 everywhere except x=0 so I dont understand why that should be ind

[EigenVector22]

so I dont understand why that should be ind

its just because how MAXIMA handles oscillatory behavior, as mentioned int the initial reply,
its not a bug in SAGE, SAGE just uses MAXIMA
(otherwise its quite intuitive that the function spends "more time" being 0 than 1, so the reflected answer should be 0)

[harshrawat-14]

Justification for limit(floor(0.5+0.5*sin(1/x)) , x=0) .

here the argument (i.e.; radians) to the sin function is itself indeterminate . as we cannot judge the state of infinity , whether it is even a integer or a rational or irrational . Hence it is indeterminable to understand the value of sin(1/x) , limit x->0 .
Actually these cases comes under a special class of limits called "DIVERGENT LIMITS(OSCILLATORY LIMITS)" , where it does not converges or points to a specific value .
Hence any function of the case (c1+c1*sin(1/x))/c3 comes under the category of INDETERMINATE .

[DaveWitteMorris]

I reported this upstream. It is now maxima bug #4530.

I am setting the status to needs info because we are waiting to hear back from maxima.

Note: The originally reported limit does not exist, because floor(0.5 + 0.5*sin(1/x)) is equal to 1 whenever sin(1/x) is equal to 1. However, if we make the coefficient of sin(1/x) smaller, then the expression is 0 everywhere (except at x=0), so the limit should be 0, but maxima still says ind. That is a maxima bug, but I'm not optimistic that it will be fixed.

[rfateman]

It is not a bug. The answer (indefinite) is correct. sin(1/x) is equal to 1 in any non-empty neighborhood of 0. Also non-equal to 1. So there is no
single limit. It is nice that Maxima figures this out. FYI,
Mathematica also provides the same answer.
So:
Sage bug? No
Maxima bug? No

[AdityaK1729]

Oh, I looked it and I have indeed made an error, as @DaveWitteMorris said I indeed have made an error in my original limit, but as @edoarad pointed out, when we reduce the coefficient of sin(1/x) to something smaller, 0.4 for instant, it is still ind

Should I edit my title/description?

[rfateman]

It occurs to me that the original poster (and maybe some of the other commenters) are conflating
floating-point numbers with finite representation or perhaps rational numbers with "real numbers".
sin(1/x) indeed is never exactly equal to 1 at any rational point, but it is 1 at an infinite number of real points.

As for the calculation of the limit of floor(0.5+0.4*sin(1/x)),
this relates more to my comment (posted on the Maxima mailing list)...
that computer algebra systems compute limits of analytic functions, primarily. Floor is not analytic.
If Maxima gets the right answer here, that's a bonus.

Maxima's limit function gives ind for this modified expression, when it could do better.
However, a more recent program to compute limits using
a method by Dominik Gruntz, gives 0.
In Maxima, the command is gruntz(...).
Mathematica gives 0 for this limit. Perhaps it uses gruntz() more often.

[rfateman]

There is no particular reason to expect Maxima to find limits of non-analytic functions. However, one alternative limit program in Maxima, gruntz(...) gets 0. So maybe it is a Sage error in not using gruntz as a backup method. I think it is generally not a great idea to use Sage to access Maxima. Given the mostly non-useful comments on your post, you might do better just to delete it all, if that is possible. Good luck.

…

On Sat, Mar 29, 2025 at 12:37 PM Aditya Khambete ***@***.***> wrote: Oh, I looked it and I have indeed made an error, as @DaveWitteMorris <https://github.com/DaveWitteMorris> said I indeed have made an error in my original limit, but as @edoarad <https://github.com/edoarad> pointed out, when we reduce the coefficient of sin(1/x) to something smaller, 0.4 for instant, it is still ind Should I edit my title/description? — Reply to this email directly, view it on GitHub <#39819 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPSB7VWRBPD5QTVLN4MKMD2W3Y7TAVCNFSM6AAAAAB2BCMZZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRUGIYTKOBZGM> . You are receiving this because you commented.Message ID: ***@***.***> [image: AdityaK1729]*AdityaK1729* left a comment (sagemath/sage#39819) <#39819 (comment)> Oh, I looked it and I have indeed made an error, as @DaveWitteMorris <https://github.com/DaveWitteMorris> said I indeed have made an error in my original limit, but as @edoarad <https://github.com/edoarad> pointed out, when we reduce the coefficient of sin(1/x) to something smaller, 0.4 for instant, it is still ind Should I edit my title/description? — Reply to this email directly, view it on GitHub <#39819 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPSB7VWRBPD5QTVLN4MKMD2W3Y7TAVCNFSM6AAAAAB2BCMZZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRUGIYTKOBZGM> . You are receiving this because you commented.Message ID: ***@***.***>

[DaveWitteMorris]

@AdityaK1729: Yes, I think it would be good to correct the formula in the title and description.

[DaveWitteMorris]

Update: The bug has been fixed in maxima, but is not yet in a stable release. This sagemath issue can be closed when we update maxima to incorporate the fix.