Puzzled by the bignum pragma

[syphilis]

Why does bignum assign integer values to Math::BigInt objects ?
Why not assign them to a Math::BigFloat object, same as is done for non-integer values ?
By allowing 2 types of objects, bignum opens itself up to issues that (AFAICS) would not arise if all values were assigned to Math::BigFloat objects - eg upgrades/downgrades from one type to another.
And I can't see that allowing Math::BigInt objects leads to any benefits.

Illuminations are most welcome.

Cheers,
Rob

[Anonymous Monk]

Probably because if you wanted everything to be a BigFloat, you'd use bigfloat instead?

There's bigint and bigrat too.

[syphilis]

Probably because if you wanted everything to be a BigFloat, you'd use bigfloat instead?

It's just that I can't see anything to be gained by mixing the two.
Sure, a BigInt has arbitrary precision, and there's a limit to the BigFloat precision - though that limit can be altered to suit.
Does bignum really want to be involved in programs where bigfloat precision fails to preserve bigint precision ?
I've had a gutful of that type of consideration with perls whose nv fails to preserve iv. It's not much fun, and I see nothing to be gained by electing to jump through that hoop.

Cheers,
Rob

[Don Coyote]

From what I gather, the concern for perl is only to represent its Scalars/Things in the way it sees as best to fit, wouldn't more options allow for better optimisation/packing decisions.

In my view, fact one everyone learns about floats is that they are not an isometry to any other type, do bigfloat and bignum pragmas have some thing to say about this? Not that im asking, just that the notion that there is such is unfamiliar to me. hence why I opted for the did you mean internally line.

I would take it that inherent incompatibilty between floats and anything else would carry into qq/bigtypes/.

---

select( ${\()}, ${\\()} ? undef : Don, defined ${\0} ? undef : Coyote, 2/3)