Bug #113943 for Math-BigInt: Possibly new bug in the Math::BigFloat

I was wrong, when I wrote "In the Math::Big* modules, shifting left by -1 is equivalent to shifting right by 1. This was true only for Math::BigFloat, and it was not according to the documentation. The documentation says blsft() and brsft() shifts left and right, and refers to the documentation in Math::BigInt, which says "Right shifting usually amounts to dividing $x by $n ** $y and truncating the result". So, the fact that you got 1.5 rather than 1, was not according to the documentation. With Math::BigInt, shifting left by a negative amount results in a NaN, and since Math::BigFloat now lets Math::BigInt do the actual shifting, that's why you got the NaN. In Perl, shifting left by a negative amount causes the bits to wrap, so while 3 >> 2 gives 0, 3 << -2 gives 13835058055282163712 (with 64 bit integer support). The equivalent in Math::BigInt is to return inf, I believe. By the way, if what you actually want to do is to multiply by a number (base) raised to some power, replace $x -> blsft($n, $b) with $x -> bmul($b -> copy() -> bpow($n))

On Mon Apr 25 04:52:14 2016, dzagashev@gmail.com wrote: Show quoted text
I have read the "analysis", and I have to admit it would be easier to take it more seriously if it weren't for all the ranting, straw man arguments, and false assumtions made there. I am more than willing to discuss my change, including how blsft() and brsft() ought to behave, but I am not going to spend time wading through a lot of ranting. I have a few replies to the "analysis". - Just because some piece of code has behaved in a certain way over many years, doesn't make that behaviour correct. Hence, changing a certain old behaviour isn't necessarily a bug. - blsft() and brsft() are so poorly documented that it is not obvious what is the correct behaviour. The documentation provided in the "analysis" is just one of several fragments. The actual documentation in the modules contain other pieces of documentation that can be interpreted differently than the one provided in the "analysis". - Considering Math::Big(Int|Float|Rat) toy modules that are too unreliable for serious use is nothing new. They have been toy modues ever since TELS redesigned these modules more than 10 years ago. Initially, my intention was to use these modules for numerical analysis of special functions, but I didn't dare, because I quickly realized that these modules contain a staggering amount of bugs, inconsistencies and a fundamentally flawed design. This has also been commented by some of the most well-known people in the Perl community. - Am I the best maintainer for these modules? Maybe not, but at least I am maintaining them. I took over as maintainer because no one else gave these modules the priority they deserved. I believe I have both reported and fixed more bugs in these modules than anyone else. And when someone has pointed out that I have, unfortunately, introduced a bug, I have fixed it quickly. - I have not claimed that Perl core has a blsft() method. However, since others have referred to << and >> as bitwise operators, and since Math::Big* overloads << and >> to directly call blsft() and brsft() I was under the impression that blsft() and brsft() were bitwise operators. - I have not claimed that << and >> in Math::Big* should emulate Perl core << and >> in every aspect. - I have not claimed that I will keep the current behaviour of blsft() and brsft().

I have reverted the changes to blsft() and brsft() in Math::BigFloat and uploaded v1.999719 of the Math-BigInt distro to CPAN.

On Tue, April 26, 2016 10:31 am, dzagashev@gmail.com via RT wrote: Show quoted text
Hello together, sorry for the late reply, I seldom check my emails these days. Thank you, Peter for mainting my pileofcrap^Wmodules! This is much appeciated, and a lot of work you probably get not thanks for :) According to the bugreport, the changes have already been reverted. I'd still like to add a bit of reasoning and history here, just for the record. Maybe this helps in the future with such decisions. There was some reasoning along the lines of "<< uses blsft() so they must be equivalent.". That's not what was intended. First: the "bigfloat" etc modules where invented to get better math into Perl without having to rewrite scripts. Even after much work, that never really works except in special cases. However, to get them even to work, we need overloaded operators. And to avoid reinventing the wheel, "<<" simply uses blsft(). That does not mean, however, that blsft() should work only on or return integers, or that the "<<" operator should actually be exactly the same as blsft()! (Yes, I know, I should have added a lot more documentation. My bad.) And second: Math::BigRat should be a superset of Math::BigFloat and this should be a superset of Math::BigInt. So a method in BigRat should return (if possible) a BigRat, in BigFloat a BigFloat - and not just truncate to BigInt. I think the confusion might come from the fact that the modules share a lot of code, design and are interwined a lot. In theory, however, you should be able to use Math::BigFloat and compute with BigFloats w/o even knowing about Math::BigInt. Anyway, the Math::Big modules have indeed not had the best history - and while my rewrite back then took staggering amounts of work it still left way too many loose ends for my taste. I probably also added a few bad design choices and bugs - sorry for that, but my (Perl) knowledge was limited back then. The rewritten modules are still, IMHO, light-years ahead than what we had before. If anyone thinks they are still insufficient for real work - well, you can always roll your own :) Thanx for reading, tels -- http://bloodgate.com/galleries/