asymptotic expansion generators related to singularity analysis

[dkrenn]

Create asymptotic expansions coming from pole singularities.

[dkrenn]

Implemented pole singularities.

---

Last 10 new commits:

​e93ce46	simplify coefficients automatically and use the faster algorithm per default
​f468de6	docu
​4a27e66	result over QQ if skip-parameter given
​e59c71f	toc entry (at top of file)
​e1aca77	SR.symbol: set parent correctly (inheritance)
​9ac89ae	Move pynac_symbol_registry to cdef attribute SR.symbols
​e06f8ae	Merge branch 'u/jdemeyer/symbolic/sub-var' of trac.sagemath.org:sage into asy/singularity-analysis
​f2573a9	calculate coefficients of singularity analysis (pole type)
​b2e375f	generator SingularityAnalysis (pole type)
​3214c83	explicitly specify a default default-precision

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​8ec2dfd

fix docstring

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​8f7195f	Trac #19576: parentheses around coefficients of asymptotic expansions
​ab1cd26	Trac #19532: Merge #19576 to fix doctest

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​9796508

Trac #19532: fix doctest

[cheuberg]

My impression is that you implemented poles and still want to implement logarithmic singularities in the same ticket. I'd suggest to restrict this ticket to poles (and raising NotImplementedError for the logarithmic singularities, as apparently done in the current code) and to leave extensions to future tickets.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​f114f9e	Trac #19532: Add to table of contents
​ede5173	Trac #19532: Minor documentation fixes
​267718d	Trac #19532: Additional tests
​0860173	Trac #19532: List log log factors, document missing implementations
​a3a6dfd	Trac #19532: Add references

[cheuberg]

I reviewed the code, doctests pass, documentation and code are mostly fine. I added a few reviewer commits, please cross-review.

There is only the question on what to do with integral alpha <= 0. Currently, the result is 0 which is certainly correct for sufficiently large values of the parameter. However, the rest of the asymptotics code as I remember it does not really assume "sufficiently large values of the parameter".

I am not really sure which result is appropriate. Several options:

• 0 - valid for sufficiently large values of the parameter. (current version)
• O(1) - correct, but bad for applications.
• raise an error
• add a warning to the documentation
• add a note to the documentation

[cheuberg]

zeta != 1 is not implemented.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​ea3dd35	small bugfix
​1529a4d	Trac #19510: Merge #19306 (due to #19879)
​b30388b	Trac #19532: Merge #19510 to fix doctest
​7f74b31	Trac #19532: Implement zeta != 1

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​0c600cf	add code for singularity analysis
​b8a52c6	add example
​e3588b6	fix: .summand --> .summands
​f6a233d	add precision keyword

[cheuberg]

pushed incorrect branch (mixup with #19944)

---

Last 10 new commits:

​9796508	Trac #19532: fix doctest
​f114f9e	Trac #19532: Add to table of contents
​ede5173	Trac #19532: Minor documentation fixes
​267718d	Trac #19532: Additional tests
​0860173	Trac #19532: List log log factors, document missing implementations
​a3a6dfd	Trac #19532: Add references
​ea3dd35	small bugfix
​1529a4d	Trac #19510: Merge #19306 (due to #19879)
​b30388b	Trac #19532: Merge #19510 to fix doctest
​7f74b31	Trac #19532: Implement zeta != 1

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​f38cdfc

Trac #19532: fix more issues with location of singularities

[dkrenn]

Replying to cheuberg:

There is only the question on what to do with integral alpha <= 0. Currently, the result is 0 which is certainly correct for sufficiently large values of the parameter. However, the rest of the asymptotics code as I remember it does not really assume "sufficiently large values of the parameter".

I am not really sure which result is appropriate. Several options:

• 0 - valid for sufficiently large values of the parameter. (current version)
• O(1) - correct, but bad for applications.
• raise an error
• add a warning to the documentation
• add a note to the documentation

I think the result should be O(0). Currently I am thinking about an implementation of such a term and playing around a bit. If you want to get this ticket to positive, then I would raise a NotImplementedError? at the moment. But give me a couple of days to figure out how O(0) would be possible.

Best, Daniel

[cheuberg]

What would O(0) mean? How would that affect #19944?

[dkrenn]

Replying to cheuberg:

What would O(0) mean?

f(n) is in O(0) if there is an N such that f(n)=0 for n >= N. Thus the coefficients of polynomials (seen as power series) would be in O(0).

How would that affect #19944?

E.g. inserting the generating function (1-z)^alpha for non-negative integers alpha would result in a O(0), but this behavior comes from this ticket here. I am not sure if #19944 would need adaptions.

[cheuberg]

Replying to dkrenn:

Replying to cheuberg:

What would O(0) mean?

f(n) is in O(0) if there is an N such that f(n)=0 for n >= N. Thus the coefficients of polynomials (seen as power series) would be in O(0).

so O(0) would be smaller than any other element in the poset and be absorbed by any other error term? Would it live in some kind of n^ZZbar with ZZbar = {- infinity} \cup ZZ?

How would that affect #19944?

E.g. inserting the generating function (1-z)^alpha for non-negative integers alpha would result in a O(0), but this behavior comes from this ticket here. I am not sure if #19944 would need adaptions.

ok, may be.

The question is whether it is worth the effort. After working on #19944 I doubt that this generator here will frequently be called outside of #19944. After all, calling #19944 with a polynomial as an argument is erroneous anyway, because polynomials do not have singularities. Thus we should never have to return O(0) so we might as well go for a warning box here and be done with the problem.

[dkrenn]

Replying to cheuberg:

Replying to dkrenn:

f(n) is in O(0) if there is an N such that f(n)=0 for n >= N. Thus the coefficients of polynomials (seen as power series) would be in O(0).

so O(0) would be smaller than any other element in the poset and be absorbed by any other error term? Would it live in some kind of n^ZZbar with ZZbar = {- infinity} \cup ZZ?

I'm afraid, we would really need a growth of 0 to make it work correctly with cartesian products.

E.g. inserting the generating function (1-z)^alpha for non-negative integers alpha would result in a O(0), but this behavior comes from this ticket here. I am not sure if #19944 would need adaptions.

ok, may be.

The question is whether it is worth the effort. After working on #19944 I doubt that this generator here will frequently be called outside of #19944. After all, calling #19944 with a polynomial as an argument is erroneous anyway, because polynomials do not have singularities. Thus we should never have to return O(0) so we might as well go for a warning box here and be done with the problem.

I am raising a special NotImplementedError now. Code follows...

[dkrenn]

I've cross-review your changes...seem to be fine.

---

New commits:

​2dff051

raise NotImplementedOZero instead of the wrong result 0

[cheuberg]

LGTM. Setting to positive despite the dependency: the dependency is only in order to avoid a merge conflict (inserting new methods at the same position); so no changes are necessary here anyway independently of the fate of #19510.

[cheuberg]

Merged #19946 and removed work-around for #19946; please cross-review.

---

New commits:

​1fc00c7	Trac #19946: fix _pushout_ for cartesian product of growth groups
​1b62954	Trac #19946: add doctests to document behavior
​24c153c	Trac #19946: reviewer commit: ReSt error
​7918417	Trac #19946: additional doctest
​bfb72dc	Trac #19532: Merge #19946
​21054cb	Trac #19532: get rid of work-around for #19946

[dkrenn]

I've merged in the dependency #19510 due to changes there and merge-conflicts here.

---

Last 10 new commits:

​5d9152c	Trac #19510: state constant factors/summands in Stirling and binomial
​2db9105	Trac #19510: separate calculation of negative powers in log_Stirling
​1471336	Trac #19946: rewrite and improve explaination of 1b62954
​9f9a23f	Trac #19961: document rpow
​101e4de	Merge branch 'u/dkrenn/t/19961' of trac.sagemath.org:sage into t/19946
​7179c78	Trac #19946: link from general doc to detailed explaination
​1259201	Trac #19946: fix typo
​37caf25	Merge branch 'u/cheuberg/t/19946' of trac.sagemath.org:sage into t/19510/asy/generators-binomial
​10cd04b	Trac #19510: major rewrite of binomial kn over n
​a71b84a	Merge remote-tracking branch 'trac/u/dkrenn/asy/generators-binomial' into t/19532/asy/singularity-analysis-generator

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​4c58608	Trac #19898: Generator for expansion of harmonic number
​adae74b	Trac #19898: Merge #19510 to resolve conflicts
​ef9cb08	Trac #19898: Merge #19306 (due to #19879)
​e193ac1	Trac #19898: sage.rings.arith -> sage.arith.all (after #19879)
​bedd23a	Trac #19898: rename harmonic_number to HarmonicNumber
​27e9e69	Trac #19898: state constant summand in documentation
​209329d	Merge branch 'u/dkrenn/asy/generators-binomial' of trac.sagemath.org:sage into t/19898/asy/harmonic-number
​4ad4524	Merge branch 'u/dkrenn/asy/harmonic-number' of trac.sagemath.org:sage into t/19532/asy/singularity-analysis-generator

[dkrenn]

Merge in #19898 to avoid a merge conflict. (Git is able to merge automatically if #19898 is handled first.)

[cheuberg]

Merged #19898 once more and added a doctest; please review this new doctest and then set to positive if satisfied.

---

Last 10 new commits:

​3d51289	Trac #19957: Merge #19946 to avoid work-around
​b606fdf	Trac #19957: remove work-around for #19946
​4346994	Trac #19957: rename e to expansion in doctests
​5d6e9b2	Trac #19957: Introduce parameter relative tolerance
​00eae5d	Merge branch 't/19957/asy/compare-with-values' into t/19510/asy/generators-binomial
​78bdd0f	Trac #19510: additional doctests using compare_with_values
​148eabb	Trac #19898: Merge #19510
​a66c377	Trac #19898: additional doctest using compare_with_values
​5dc6f58	Trac #19532: Merge #19898
​2b95429	Trac #19532: additional doctest using compare_with_values

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​a4eaf82

Trac #19532: add relative tolerance to doctests introduced on this ticket