Re: Math::BigInt and bigint with non-integers

2021-08-20 Thread Peter John Acklam
tor. 19. aug. 2021 kl. 16:40 skrev Dan Book :
>
>
> Truncation to integer seems the most useful and expected behavior to me.
Not sure if the "overloading of constants" case should be affected, would
people depend on it staying unmodified?

I agree on truncation to integer. This is consistent with how Perl treats
non-integers in integer context. E.g., $a[0.9] returns $a[0], not $a[1].

I know nothing about the context in which people use "use
Math::BigInt=:constant" or "use bigint". I would suspect that these are
only used when people are using integers only. As soon as a non-integer
interacts with the overloaded literal integers, it is converted to an
integer (with "bignum")

$ perl -Mbigint -wle 'print 2 + 3.16'
5

or a NaN (with "Math::BigInt")

$ perl -MMath::BigInt=:constant -wle 'print 2 + 3.16'
NaN

It seems most sensible to me that both cases should return 5.

It would be nice if Math::BigInt->new("3.16") also returned 3, not NaN as
now. However, people might rely on this behaviour. I might search through
the CPAN modules and see if I can find any use cases.

Peter


Re: Math::BigInt and bigint with non-integers

2021-08-19 Thread Timothe Litt
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


Re: Math::BigInt and bigint with non-integers

2021-08-19 Thread Dan Book
On Thu, Aug 19, 2021 at 4:18 AM 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?
>

Truncation to integer seems the most useful and expected behavior to me.
Not sure if the "overloading of constants" case should be affected, would
people depend on it staying unmodified?

-Dan