Bug #114004 for Math-Polynomial: t/11_math_bigrat.t fails with recent Math-BigInt (>= 1.999718)

You need to use Math::BigRat v0.260803 or later. Changes were made to the Math-BigInt distribution which required changes to the Math-BigRat distribution too. Because of this, certain combinations of the two distributions don't work together.

As Peter John Acklam correctly observed, incompatible versions of Math::BigInt and Math::BigRat can lead to Math::BigRat giving wrong results. Upgrading both to their latest releases should fix the problem. Math-Polynomial-1.009 now lists Math::BigInt and Math::BigRat as recommended dependencies. This should make future reports more meaningful as versions of prerequisites will be included. Thank you for testing this. As Math-Polynomial appears not to take the blame this time, I'll close the ticket when reports for release 1.009 confirm our findings. -Martin

The metadata changes in Math-Polynomial-1.009 failed to make test reports actually more meaningful. The next version will have an explicit diagnostic listing relevant module versions. Note that all evidence so far suggests that our test failure is triggered by errors in rational arithmetic which in turn stems from incompatible combinations of Math::BigRat and Math::BigInt versions. While it is very unfortunate that such version combinations exist, there is not much we can do about it other than requiring quite recent versions of both modules. Just ignoring the failure does not feel right. Broken arithmetic can not simply be tolerated. Math::Polynomial of course would be good to use with other coefficient types. We could perhaps come up with run-time checks guarding against really crazy coefficient behaviour. First, however, we'll try to improve test diagnostics in order to give some guidance to users suffering from well-known incompatibilities. -Martin

On 2016-08-06 15:12:47, MHASCH wrote: Show quoted text
Just a recommendation means that smokers and users may still see test failures (see http://matrix.cpantesters.org/?dist=Math-Polynomial%201.011 ). So either the minimum version should be a hard requirement, or the failing test should be skipped if Math::BigRat is not new enough.

On Fri Oct 14 13:43:39 2016, SREZIC wrote: Show quoted text
You are right that the change did not make the failures go away. I had figured if the new BigInt version came via recommendation, more recommemdations might do the trick. I don't like the idea to make Math::Big<whatever> a mandatory prerequisite. These modules are not and will not be required. They are just supposed to make good coefficient spaces. Now unfortunately Math::BigInt got severely broken and Math::BigRat got its own distro so it is not to be taken for granted that a BigRat version recent enough to cope with the problem is available on a platform where Math::Polynomial is going to be installed. Consequently, whether or not Math::Polynomial can be used together with Math::BigRat to do symbolic math depends on circumstances we (Math::Polynomial maintainers) can not control. As long as the root problem does not get fixed, it seems best to make our test suite independent of BigInt/BigRat behaviour and stop recommending these modules as being compatible. Look out for Math-Polynomial-1.012 in the near future. -Martin

Peter, On Sun, Nov 20, 2016 at 08:51:02AM -0500, Peter John Acklam via RT wrote: Show quoted text
Thank you for your cooperation in settling this issue. I can see now that asking you to take back the change to blsft() and brsft() in Math-BigInt-1.999717, that breaks older versions of Math::BigRat which in turn breaks any client code attempting do do rational arithmetic using an unfortunate combination of these modules, would be a bit much to ask. You certainly should be able to decide where backwards-compatibility must be sacrificed in favour of progress. Our problem here would go away if we were able to force clients to update Math::BigRat together with Math::BigInt. While the Perl module infrastructure of today lacks a general solution to impose restrictions on reverse dependencies, I can see a special solution for our case. After all, both modules are under active development by the same author and maintainer. And here is my suggestion: Include Math::BigRat in the Math-BigInt distribution for now. You'll be free to continue parallel development of the "Big Three" big number modules as before, but with much less danger for downstream code to be left with a problematic combination of these. Future incompatible changes, of course, could be made easier to cope with in a number of ways. For one thing, I'd like methods to change their name when there is new semantics. That way, old and new semantics could coexist for a while with some sort of deprecation music. Once deprecation was over, clients would fail spectacularly rather than giving wrong results silently. An important math library, and an arbitrary precision one at that, should go to great lengths to avoid the latter. The unification of Math::BigInt, Math::BigFloat, and now Math::BigRat, into one distribution does not need to be permanent. It should last long enough for the mainstream to catch up, and of course as long as substantial changes affecting all three of them are to be anticipated. Could you be persuaded to do this? I'd gladly include updated module recommendations into my distributions then. I consider it the best way to weed out outdated Math::BigRat versions from systems where only Math::BigInt is intentionally being upgraded. -Martin