incorrect handling of constant term when creating power series

Question

incorrect handling of constant term when creating power series

DaveWitteMorris opened this issue 5 years ago · 13 comments

As reported by user TBK in this sage devel thread, the series method sometimes returns an incorrect power series in which a constant term has erroneously been multiplied by a power of x:

    sage: ((1-sqrt(1-x))/x + 0).series(x,3)
    1/2 + 1/8*x + 1/16*x^2 + Order(x^3)  # correct
    sage: ((1-sqrt(1-x))/x + 123).series(x,3)
    123*x^(-1) + 1/2 + 1/8*x + 1/16*x^2 + Order(x^3)  # wrong !!!

Depends on #31679

Component: symbolics

Keywords: pynac, series

Author: Dave Morris

Branch/Commit: 1da52de

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/31645

Answer 1 · 2021-04-11T04:21:13.000Z

comment:1

Diagnosis: Laurent polynomials are stored as a pair consisting of a polynomial and an offset n that represents multiplication by x^n. Pynac's add::useries method fails to account for the offset when adding the constant term to a power series.

This should be easy to fix, so I should be able to upload a PR soon.

Answer 2 · 2021-04-11T18:46:34.000Z

Branch: public/31645

Answer 3 · 2021-04-11T18:52:00.000Z

Commit: a135bbb

Answer 4 · 2021-04-11T18:52:00.000Z

comment:3

The PR fixes the bug by moving the handling of the constant term to the initialization phase, where the offset is known to be 0.

With this PR applied, we get the correct result for the example in the ticket description:

sage: ((1-sqrt(1-x))/x + 123).series(x,3)
247/2 + 1/8*x + 1/16*x^2 + Order(x^3)

As a doctest, the PR uses the following very simple example that was also giving a wrong answer:

sage: (x^(-1) + 1).series(x,1)  # wrong answer !!!
2*x^(-1) + Order(x)

My recent pynac patches had merge conflicts, but I rebased this one on #31554 (hence the dependency), so I think it should merge cleanly. Only the last 3 commits come from this ticket ("trac 31645 handling ...", "add doctest", and "increment pynac patch level").

This is a critical bug, so I hope it can be merged in 9.3.

Last 10 new commits:

`b6f9170`	`increment package version`
`96b0f8b`	`add 32-bit known bug tags`
`ed6cac2`	`Merge branch 'public/31554' of git://trac.sagemath.org/sage into t/31479/public/31479v2`
`2364860`	`build/pkgs/pynac/package-version.txt: Bump patch level`
`b0b074e`	`Merge #31479`
`eeb6cc2`	`build/pkgs/pynac/package-version.txt: Bump patch level`
`04d0090`	`Merge branch 'public/31479v2' of git://trac.sagemath.org/sage into t/31554/public/31554`
`74bcb8a`	`trac 31645 handling of constant term in series`
`81e530b`	`add doctest`
`a135bbb`	`increment pynac patch level`

Answer 5 · 2021-04-11T18:52:00.000Z

Dependencies: #31554

Answer 6 · 2021-04-11T22:52:45.000Z

comment:4

LGTM.

Answer 7 · 2021-04-11T22:52:45.000Z

Reviewer: Travis Scrimshaw

Answer 8 · 2021-04-11T23:00:28.000Z

comment:5

Thanks!

Answer 9 · 2021-04-19T05:07:52.000Z

Changed branch from public/31645 to public/31645r1

Answer 10 · 2021-04-19T05:11:13.000Z

Changed commit from a135bbb to 1da52de

Answer 11 · 2021-04-19T05:11:13.000Z

Changed dependencies from #31554 to #31679

Answer 12 · 2021-04-19T05:11:13.000Z

comment:8

Rebased on #31679 (which replaced #31554), and updated the patch version again.

New commits:

`3fde2ac`	`trac 31479: pynac's poly_mul_expand`
`5501577`	`add doctests`
`6bf6ec0`	`increment package version`
`296d4c7`	`add 32-bit known bug tags`
`ef84adf`	`Merge branch 'public/31554' of git://trac.sagemath.org/sage into #31679polymulexpand`
`2b88eb5`	`fix doctest for 32-bit`
`9aec019`	`trac 31645 handling of constant term in series`
`89d65ff`	`add doctest`
`1da52de`	`increment pynac patch level again`

Answer 13 · 2021-04-25T12:14:05.000Z

Changed branch from public/31645r1 to 1da52de