in reply to is it a BigInt bug?

To put it more simply, I gather you are asking about the difference between these two cases:
perl -Mbigint -wle '($x,$y)=split " ","9 2"; $z = $x / $y; print $z' 4.5 perl -Mbigint -wle '($x,$y)=map {$_+= 0} split " ","9 2"; $z = $x / $y +; print $z' 4
The manual for bigint says "Integer constants are created as proper BigInts. Floating point constants are truncated to integer."

It doesn't say anything about interpolating strings into "proper Bigints", so… while this behavior does seem to go against the spirit of DWIM, it's not officially a bug if strings have to be coerced explicitly into numbers in order for them to become bigints.

Or was there some other issue that you were trying to describe?

Replies are listed 'Best First'.
Re^2: is it a BigInt bug?
by rsFalse (Chaplain) on Jul 20, 2014 at 17:54 UTC
    Thank you, graff, it was what I mean. I thought it must DWIM, and "use bigint" must not work in different way from "use bigint". I found real number instead of integer in this case at the bottom, later wrote here.
    use bigint; ($m,$k)=split/ /,<>; print $k<$m? $m / ++$k : -1
    stdin="10 2\n" stdout=3.33... One more strange is that increment of "2\n" did not change it to a number.
      increment of "2\n" did not change it to a number.

      Why do you say that?

      13:45 >perl -Mbigint -wE "my ($m, $k) = split / /, qq[10 2\n]; say qq[ +>$k<]; ++$k; say qq[>>$k<<];" >2 < >>3<< 13:49 >

      Update (31 Aug 14): Fixed typo: changed ++k to ++$k.

      Auto-increment has here converted $k from a string to a number, as can be seen from the loss of the trailing newline. The same effect is produced by $k++ or $k += 1.

      Hope that helps,

      Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

        But if ++$k becomes the number 3, why it gives different answer?
        print $k<$m? $m / ++$k : -1 # gives 3.(3) print $k<$m? $m / 3 : -1 # gives 3