Bug #121649 for Math-Polynomial-Solve: t/21-poly.t fails

Sat May 13 05:00:12 2017 SREZIC [...] cpan.org - Ticket created

Subject:

t/21-poly.t fails

My smokers started to report a test failure: ... # Failed test ' [ 67, -4961, 137445, -1682934, 7551423, 1950773 ], ascending order' # at t/21-poly.t line 48. # Looks like you failed 1 test of 20. t/21-poly.t ....... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/20 subtests ... Not sure about the reasons here. I first thought it's the latest Math-Utils release causing the failures, but I see also pass reports with Math::Utils 1.09.

Sat May 13 15:40:09 2017 jgamble [...] cpan.org - Correspondence added

On Sat May 13 05:00:12 2017, SREZIC wrote: Show quoted text

> My smokers started to report a test failure: > > ... > # Failed test ' [ 67, -4961, 137445, -1682934, 7551423, 1950773 ], > ascending order' > # at t/21-poly.t line 48. > # Looks like you failed 1 test of 20. > t/21-poly.t ....... Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/20 subtests > ... > > Not sure about the reasons here. I first thought it's the latest Math- > Utils release causing the failures, but I see also pass reports with > Math::Utils 1.09.

Problem was covered up by incorrect used of pl_evaluate() in my tests, and which got revealed when I extended pl_evaluate()'s handling of its arguments in version 1.10 of Math::Utils. In other words, the error has always been there, it's just been unreported until now. It is probably a case of loss of precision, but we'll see.

Sat May 13 15:40:09 2017 The RT System itself - Status changed from 'new' to 'open'

Tue May 16 13:20:36 2017 jgamble [...] cpan.org - Correspondence added

Problem resolved in version 2.80. Test was deliberately "dirty", and margin of error was a little too narrow to handle it.

Tue May 16 13:20:46 2017 jgamble [...] cpan.org - Status changed from 'open' to 'resolved'

Tue May 16 13:20:52 2017 jgamble [...] cpan.org - Fixed in 2.80 added