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: sage-6.3
Component: symbolics Keywords: maxima limit
Cc: kcrisman Merged in:
Authors: Karl-Dieter 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/sage-support/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 sage-support thread).

Change History (15)

comment:1 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:2 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:3 Changed 6 years ago by pbruin

  • Dependencies set to #13973

This is now fixed upstream, and after #13973 we get

sage: n = var('n')
sage: assume(n>0)
sage: series = -(3*n^2 + 1)*(-1)^n/sqrt(n^5 + 8*n^3 + 8)
sage: limit(series, n=infinity)
0

comment:4 Changed 6 years ago by tscrim

Can you add the doctest Peter (since you know which doctests have been added where)?

comment:5 Changed 6 years ago by kcrisman

I hopefully should have something ready for this momentarily based on those tickets.

comment:6 Changed 6 years ago by kcrisman

  • Authors set to Karl-Dieter Crisman
  • 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 kcrisman

  • Branch set to u/kcrisman/limit_fix_doc_15386
  • Commit set to b6657b95ff01453ef73afb8e5390840f9cc314f2

Last 10 new commits:

1dc012fTrac 13973: fix doctests to adjust for differently presented solutions
741e9a4Trac 13973: fix integration doctest with changed output
0b4b0d0Trac 13973: use "domain: real" for example with integral
13d48c2Trac 13973: fix doctests with changed floating point format/precision
a130eedTrac 13973: realpart should be real_part
3d927bfMerge remote-tracking branch 'trac/u/pbruin/13973-maxima_update' into ticket/13712
c715aabMerge branch 'public/ticket/inf_sum_doctest-13712' of git://trac.sagemath.org/sage into ticket/11894-maxima_sum_zero_division
1dd0f05Trac 11894: add doctest for error detection in Maxima sum
0ede45cMerge branch 'u/pbruin/11894-maxima_sum_zero_division' of trac.sagemath.org:sage into maxima_upgrade
b6657b9Trac #15386 - document that Maxima 5.33 fixes this limit

comment:8 follow-up: Changed 6 years ago by kcrisman

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 tscrim

  • 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 pbruin

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 follow-up: Changed 6 years ago by 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 queue-like 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 ; follow-up: Changed 6 years ago by pbruin

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 queue-like 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 kcrisman

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.

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 pbruin

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 vbraun

  • Branch changed from u/kcrisman/limit_fix_doc_15386 to b6657b95ff01453ef73afb8e5390840f9cc314f2
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.