|File: [cvs.NetBSD.org] / pkgsrc / math / p5-Math-BigInt / distinfo (download)
Revision 1.6, Sat May 13 00:52:04 2017 UTC (3 years ago) by wen
CVS Tags: pkgsrc-2018Q1-base, pkgsrc-2018Q1, pkgsrc-2017Q4-base, pkgsrc-2017Q4, pkgsrc-2017Q3-base, pkgsrc-2017Q3, pkgsrc-2017Q2-base, pkgsrc-2017Q2
Changes since 1.5: +5 -5
Update to 1.999811
Upstream changes: 2017-03-15 v1.999811 pjacklam
* Fix an old in the Math::BigFloat methods as_hex(), as_oct(), and as_bin()
methods resulting in loss of accuracy. This bug was introduced in bug in
Math-BigInt-1.76. Due to a naive copy and paste by me, and lack of tests,
this bug was also present in the newer to_hex(), to_oct(), and to_bin()
methods. This shows the bug, as it did not print "0xffff...":
print Math::BigFloat -> from_hex("f" x 30) -> as_hex();
* Fix incorrect formatting in the output from the Math::BigFloat methods
to_hex(), to_oct(), and to_bin() when the output was zero. A prefix was
added when it shouldn't have been.
* Add tests to bigintpm.inc and bigfltpm.inc for better testing of as_hex(),
as_oct(), and as_bin() as well as to_hex(), to_oct(), and to_bin().
* "Synchronize" tests and code formatting in bigintpm.inc and bigfltpm.inc.
2017-03-01 v1.999810 pjacklam
* CPAN RT #120240 revealed that the problems with undefined values is still
present. After a close examination, I believe the only way to get this
really working is to to make blog() call objectify() differently depending
on whether the base for the logarithm is undefined or not. That way we can
avoid objectify() converting the undefined value to a zero. Ideally, we
should warn about undefined values when used in any other context, but we'll
handle that in a later release. See also the related changelog entry for
* Fix the way the argument count is computed in objectify(). When an argument
count of 0 is given, it means that we should objectify all input arguments.
However, it turned out that the actual argument count was computed
* Fix CPAN RT #120242 rearding c3 method resolution.