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 | [reply] |
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)
| [reply]
[d/l] |
Incompatibility? A float is just two integers that plug into the formula X * 2 ** Y. If you make X and Y arbitrary precision, many things can be converted to floats and back without loss of precision. And, every float can be represented as a rational number. (if Y is positive, it's just a bigint. If Y is negative, that's your denominator for a rational number)
| [reply]
[d/l] |
