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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to