Dear All, I have attempted to add some more tests for sqrfree_parfrac() and it turned out that GiNaC crashes on x*(x^2-1)^(-1) with terminate called after throwing an instance of 'std::runtime_error' what(): matrix::solve(): inconsistent linear system Thus some further investigation is required in this routine. Best wishes, Vladimir ________________________________________ From: Vladimir V. Kisil <V.Kisil@leeds.ac.uk> Sent: 23 July 2020 23:08 To: GiNaC-devel List Cc: vittorio del duca; Claude Duhr; ginac-list@ginac.de; Konstantin Leyde; Vladimir V. Kisil Subject: Re: Sqrfree_parfrac Issue GiNaC Dear Konstantin, Many thanks for reporting the bug with a detailed description. I am attaching a patch to fix it. Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Maps https://doi.org/10.1142/p835 Soft: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter notebooks: https://github.com/vvkisil/MoebInv-notebooks ________________________________________ From: GiNaC-list <ginac-list-bounces@ginac.de> on behalf of Konstantin Leyde <konstantin.leyde@live.com> Sent: 22 July 2020 19:16 To: ginac-list@ginac.de Cc: vittorio del duca; Claude Duhr Subject: [GiNaC-list] Sqrfree_parfrac Issue GiNaC Hello, My name is Konstantin Leyde, and I am a master student in physics at the ETH Zurich. For my thesis project, I have been working with the GiNaC library, and I have encountered an issue with the partial fractioning (sqrfree_parfrac) routine: Unless I misunderstood the way the sqrfree_parfrac routine works, it appears that for special cases, the output of the sqrfree_parfrac routine misses a numerical prefactor for one term, and thus returns the wrong answer. Please find attached a pdf, that explains the problem in more detail. In this pdf (as well as separately) we have attached the code that shows the issue. Many thanks in advance, Best wishes, Konstantin

Vladimir, On 24.07.20 00:08, Vladimir V. Kisil wrote:

Many thanks for reporting the bug with a detailed description. I am attaching a patch to fix it.

Thanks very much for your patch. It seems fine to me, I've only one question: You copied the comment about Yun's algorithm from the sqrfree() function. But does the last sentence ("For completeness, we'll also have to recurse...") really apply here? As far as I can see, it should be removed. -richard.

Hi, On 24.07.20 00:08, Vladimir V. Kisil wrote:

Many thanks for reporting the bug with a detailed description. I am attaching a patch to fix it.

I've applied the patch (as you've surely noticed, Vladimir). However, I am beginning to think that it is best to fix sqrfree_yun such that no external workarounds are necessary. It's a little bit tricky: The sign seems to get lost in the content part of the input polynomial. (Remember that it may itself be a polynomial in other variables.) And the unit part is not deterministic for multivariate polynomials. I'm working on a patch. -richard.