Consistency is good. A case could be made for either truncating to integer, or rounding to integer.

I'm inclined toward round - since int() is a builtin (round isn't), which makes it easy to get the truncate behavior. And one is more likely to get a mathematically sensible result. On the other hand, changing long-standing behavior may wake the dragons. I don't like bug compatibility switches, but in this case a "use Math::Biging qw/roundtoint/" (or whatever you choose) might be worth considering. Unless you're up for dragonfire... On 19-Aug-21 04:17, Peter John Acklam wrote: > Hi! > > I would like some input on how the Math::BigInt module and bigint pragma > should handle non-integers. The current behaviour is rather inconsistent. > > The new() constructor converts a non-integer to a Math::BigInt NaN: > > $ perl -MMath::BigInt -wle 'print Math::BigInt -> new("3.16")' > NaN > > A math operation that returns a non-integer, returns a Math::BigInt > with the > truncated value: > > $ perl -MMath::BigInt -wle 'print Math::BigInt -> new("10") -> > bsqrt()' > 3 > > Math::BigInt with overloading of constants, leave a non-integer as an > unmodified Perl scalar: > > $ perl -MMath::BigInt=:constant -wle 'print 3.16' > 3.16 > > However, when the "bigint" pragma is used for overloading constants, a > non-integer becomes a Math::BigInt with the truncated value: > > $ perl -Mbigint -wle 'print 3.16' > 3 > > I'm not saying that all four cases should return the same value, but > returning three different values seems too much. Any suggestions? > > Cheers, > Peter

**
OpenPGP_signature**

*Description:* OpenPGP digital signature