Opened 6 years ago

Closed 6 years ago

# Maxima is confused about limits at infinity

Reported by: Owned by: ddrake major sage-6.3 symbolics maxima limit kcrisman Karl-Dieter Crisman Travis Scrimshaw Fixed upstream, in a later stable release. b6657b9 (Commits) b6657b95ff01453ef73afb8e5390840f9cc314f2 #13973, #11894, #13712

### Description

```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).

### 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:

 ​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 remote-tracking branch 'trac/u/pbruin/13973-maxima_update' into ticket/13712` ​c715aab `Merge branch 'public/ticket/inf_sum_doctest-13712' of git://trac.sagemath.org/sage into ticket/11894-maxima_sum_zero_division` ​1dd0f05 `Trac 11894: add doctest for error detection in Maxima sum` ​0ede45c `Merge branch 'u/pbruin/11894-maxima_sum_zero_division' of trac.sagemath.org:sage into maxima_upgrade` ​b6657b9 `Trac #15386 - document that Maxima 5.33 fixes this limit`

### comment:8 follow-up: ↓ 9 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

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: ↓ 12 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: ↓ 13 Changed 6 years ago by pbruin

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.