Opened 6 years ago
Closed 6 years ago
#15386 closed defect (fixed)
Maxima is confused about limits at infinity
Reported by:  ddrake  Owned by:  

Priority:  major  Milestone:  sage6.3 
Component:  symbolics  Keywords:  maxima limit 
Cc:  kcrisman  Merged in:  
Authors:  KarlDieter Crisman  Reviewers:  Travis Scrimshaw 
Report Upstream:  Fixed upstream, in a later stable release.  Work issues:  
Branch:  b6657b9 (Commits)  Commit:  b6657b95ff01453ef73afb8e5390840f9cc314f2 
Dependencies:  #13973, #11894, #13712  Stopgaps: 
Description
From https://groups.google.com/forum/#!topic/sagesupport/dwR4kuBmiQo :
n = var('n') assume(n>0) series = (3*n^2 + 1)*(1)^n/sqrt(n^5 + 8*n^3 + 8) limit(series, n=infinity) 38/25*pi^2*und
...when the limit is clearly zero.
The problem seems related to the n^2
in the numerator:
sage: series = (1)*(1)^n/sqrt(n^5 + 8*n^3 + 8) sage: limit(series, n=infinity) 0 sage: series = (n^2)*(1)^n/sqrt(n^5 + 8*n^3 + 8) sage: limit(series, n=infinity) 38/75*pi^2*und
This seems to be an upstream problem with Maxima (see the sagesupport thread).
Change History (15)
comment:1 Changed 6 years ago by
 Milestone changed from sage6.1 to sage6.2
comment:2 Changed 6 years ago by
 Milestone changed from sage6.2 to sage6.3
comment:3 Changed 6 years ago by
 Dependencies set to #13973
comment:4 Changed 6 years ago by
Can you add the doctest Peter (since you know which doctests have been added where)?
comment:5 Changed 6 years ago by
I hopefully should have something ready for this momentarily based on those tickets.
comment:6 Changed 6 years ago by
 Dependencies changed from #13973 to #13973, #11894, #13712
 Report Upstream changed from Not yet reported upstream; Will do shortly. to Fixed upstream, in a later stable release.
 Status changed from new to needs_review
My apologies for adding the dependencies, I'm still figuring out how to use git properly in these situations and don't want to make things confusing.
comment:7 Changed 6 years ago by
 Branch set to u/kcrisman/limit_fix_doc_15386
 Commit set to b6657b95ff01453ef73afb8e5390840f9cc314f2
Last 10 new commits:
1dc012f  Trac 13973: fix doctests to adjust for differently presented solutions

741e9a4  Trac 13973: fix integration doctest with changed output

0b4b0d0  Trac 13973: use "domain: real" for example with integral

13d48c2  Trac 13973: fix doctests with changed floating point format/precision

a130eed  Trac 13973: realpart should be real_part

3d927bf  Merge remotetracking branch 'trac/u/pbruin/13973maxima_update' into ticket/13712

c715aab  Merge branch 'public/ticket/inf_sum_doctest13712' of git://trac.sagemath.org/sage into ticket/11894maxima_sum_zero_division

1dd0f05  Trac 11894: add doctest for error detection in Maxima sum

0ede45c  Merge branch 'u/pbruin/11894maxima_sum_zero_division' of trac.sagemath.org:sage into maxima_upgrade

b6657b9  Trac #15386  document that Maxima 5.33 fixes this limit

comment:8 followup: ↓ 9 Changed 6 years ago by
Again, sorry for this; only the last commit b6657b9 is relevant. If someone has a better idea for how to make this work properly I'm all ears.
comment:9 in reply to: ↑ 8 Changed 6 years ago by
 Reviewers set to Travis Scrimshaw
 Status changed from needs_review to positive_review
Replying to kcrisman:
Again, sorry for this; only the last commit b6657b9 is relevant.
That's all we [the reviewers] need to know (and we can also do git diff <base_branch>
too).
LGTM.
comment:10 Changed 6 years ago by
In hindsight you could have based the commit on #11894 (which includes the other dependencies), or even on #13973 (since #11894 and #13712 only make changes in a different file than your patch). A "minimalist" solution would be to make the change on a clean development branch and to test with #13973 merged, but not to push this merge commit. As I see it, the tickets in the "dependencies" field do not necessarily have to be merged into the branch for this ticket.
It is practically inevitable that many Trac tickets end up with more dependencies (and merge commits) than strictly necessary, so let's not worry about that too much. I agree with Travis's positive review.
comment:11 followup: ↓ 12 Changed 6 years ago by
Thanks. The problem is that I don't know how to base things on other tickets. I'm very naively following the developer guide. I finally figured out how to do this efficiently with Mercurial queues only a year or two before the git switch, so now it will take time to figure this out... No, you are right that the only reason they "depend" on the other tickets is because of this queuelike thing I did.
I do think the minimalist solution would be confusing for testers, because ideally one would want to check out a branch and have it "Just work". This was what I ran into while testing #13712. :(
comment:12 in reply to: ↑ 11 ; followup: ↓ 13 Changed 6 years ago by
Replying to kcrisman:
Thanks. The problem is that I don't know how to base things on other tickets. I'm very naively following the developer guide. I finally figured out how to do this efficiently with Mercurial queues only a year or two before the git switch, so now it will take time to figure this out... No, you are right that the only reason they "depend" on the other tickets is because of this queuelike thing I did.
What I meant by "basing a commit on another ticket" is what is described in the section "Branching out" on the page you linked to. When you create a branch, it will be based on the current branch, unless you specify an alternative base (with git branch NAME BASE
or git checkout b NAME BASE
, where NAME
is the name of the new branch and BASE
the existing branch on which the new one should be based). This can only take a single dependency into account; if there are multiple dependencies you still have to add them with git merge
after creating the branch.
I do think the minimalist solution would be confusing for testers, because ideally one would want to check out a branch and have it "Just work". This was what I ran into while testing #13712. :(
Good point. It's probably confusing for the patchbot as well...
comment:13 in reply to: ↑ 12 Changed 6 years ago by
What I meant by "basing a commit on another ticket" is what is described in the section "Branching out" on the page you linked to. When you create a branch, it will be based on the current branch, unless you specify an alternative base (with
git branch NAME BASE
orgit checkout b NAME BASE
, whereNAME
is the name of the new branch andBASE
the existing branch on which the new one should be based). This can only take a single dependency into account; if there are multiple dependencies you still have to add them withgit merge
after creating the branch.
Ah, I see. So rather than just making all of these tickets part of the same local branch on my computer, I should have
 imported the Maxima branch
 created a new branch based on that for ticket A
 finished that
 gone back to the Maxima branch
 created a new branch for the next ticket B
 done that
 and so forth
Is that right? And that would have avoided some of the merges too. Maybe.
comment:14 Changed 6 years ago by
Yes, that is the idea. I'm not saying that you should have done that, but it's somewhat cleaner in the case that there are no dependencies between tickets A and B.
comment:15 Changed 6 years ago by
 Branch changed from u/kcrisman/limit_fix_doc_15386 to b6657b95ff01453ef73afb8e5390840f9cc314f2
 Resolution set to fixed
 Status changed from positive_review to closed
This is now fixed upstream, and after #13973 we get