On Thu Apr 28 15:07:42 2016, nospam-abuse@bloodgate.com wrote:

Show quoted text>
> (Yes, I know, I should have added a lot more documentation. My bad.)

The lack of documentation makes it more difficult to determine what is a
big. Without the documentation there is no reference stating how it should
actually work. But lack of documentation is just one part of the problem
-- equally bad is all the documentation that is wrong.
Here are some cases extracted from just a few lines in Math::BigFloat:
- Output values are BigFloat objects (normalized), except for bstr() and
bsstr().
Wrong. The parts() method returns BigInt objects, not BigFloats.
- The string output will always have leading and trailing zeros stripped
and drop a plus sign.
Wrong. Zeros are padded to the current accuracy or precision. E.g.,
the number 2 with accuracy 3 prints "2.00".
- The input ' -123 123 123' will cause bsstr() to print '-123123123E0'.
Wrong. Firstly, the input ' -123 123 123' is invalid and will produce
a NaN. Secondly, if the input was valid, the output would be
'-123123123e+0', with a lower-case 'e' and a sign in the exponent.
- bsstr() returns a string in scientific notation.
Questionable. The value of "3141592e-6" is correct, but standard
scientific notation is "3.141592e+0" or ".3141592e+1", the latter
possibly with a leading zero.

Show quoted text> And second: Math::BigRat should be a superset of Math::BigFloat and this
> should be a superset of Math::BigInt.

That hardly makes sense, since rational numbers is not a superset of
floating point numbers. However, both rational numbers and floating point
numbers are supersets of integers.
In any case, I can not make sens of the way it is implemented. Currently,
a Math::BigInt object is a sign and an integer. And it would make sense if
a Math::BigFloat object was a Math::BigInt with an added fraction part,
but that isn't at all how it is implemented. The only thing a
Math::BigInt, a Math::BigFloat and a Math::BigRat have in common is the
sign. And with that implementation, it doesn't make sense that they are
subclasses of each other. If this wasn't enough, Math::BigFloat->isa()
tells that Math::BigFloat isn't a Math::BigInt after all. There is no end
to the mess.

Show quoted text> If anyone thinks they are still insufficient for real work - well, you
> can always roll your own :)

That is just arrogant. Math::BigInt, Math::BigFloat, and Math::BigRat are
in the Perl distribution, so people expect them to work properly.