Closed p5pRT closed 20 years ago
Until you do it in separate steps\, 'time % -60' is never negative. This smells like a spurious NV conversion. Somewhere.
Nat
Nathan Torkington writes:
perl -le 'print time % -60' perl -le '$x = time; print $x % -60' perl -le '$x = time; $y = $x % -60; print $y'
Until you do it in separate steps\, 'time % -60' is never negative. This smells like a spurious NV conversion. Somewhere.
Is not it that time may take an argument\, and % may preceed an identifier?
Ilya
Ilya Zakharevich writes:
perl -le 'print time % -60' perl -le '$x = time; print $x % -60' perl -le '$x = time; $y = $x % -60; print $y'
Is not it that time may take an argument\, and % may preceed an identifier?
I don't think so. The second case\, which doesn't give an argument to time()\, prints the same thing as the first case.
Nat
Nathan Torkington \gnat@​frii\.com wrote
perl -le 'print time % -60' perl -le '$x = time; print $x % -60' perl -le '$x = time; $y = $x % -60; print $y'
Until you do it in separate steps\, 'time % -60' is never negative. This smells like a spurious NV conversion. Somewhere.
Nope. It's a false optimisation. The last time it showed up\, the example was something like
perl -le 'print time; print time*1000'
I don't recall the details\, but basically Perl is saying something like "I know time() returns an IV\, so I know the operation (* or %) is on integers\, so I'll force `use integer'". So you're getting the altered semantics that you get from `use integer'.
I also don't recall why this didn't get fixed - whether it was just lack of tuits\, lack of understanding of the relevant code (that's my excuse)\, or a desire to put performance above correct semantics.
Mike Guy
On Sat\, 23 Oct 1999 16:24:17 BST\, "M.J.T. Guy" wrote:
Nathan Torkington \gnat@​frii\.com wrote
perl -le 'print time % -60' perl -le '$x = time; print $x % -60' perl -le '$x = time; $y = $x % -60; print $y'
Until you do it in separate steps\, 'time % -60' is never negative. This smells like a spurious NV conversion. Somewhere.
Nope. It's a false optimisation. The last time it showed up\, the example was something like
perl -le 'print time; print time*1000'
I don't recall the details\, but basically Perl is saying something like "I know time() returns an IV\, so I know the operation (* or %) is on integers\, so I'll force `use integer'". So you're getting the altered semantics that you get from `use integer'.
I also don't recall why this didn't get fixed - whether it was just lack of tuits\, lack of understanding of the relevant code (that's my excuse)\, or a desire to put performance above correct semantics.
AFAIK this particular bug in modulus has never come up before\, or I would have fixed it. :-) Note that the "consistent C modulus" behavior based on C\
Sarathy gsar@ActiveState.com
Gurusamy Sarathy \gsar@​ActiveState\.com writes:
+{ + use integer; + $x = length("abc") % -10; + print $x == 3 ? "ok 6\n" : "# expected 3\, got $x\nnot ok 6\n"; +} End of Patch.
Is this safe?
Under 'use integer' you get the %-operator as implemented by C and C allow more than one result to be correct for negative operands. Perhaps something like is safer:
use integer; $x = length("abc") % -10; $y = 3 % -10; print $x == $y ? "ok 6\n" : "# expected $y\, got $x\nnot ok 6\n";
Regards\, Gisle
On 24 Oct 1999 12:25:01 +0200\, Gisle Aas wrote:
Under 'use integer' you get the %-operator as implemented by C and C allow more than one result to be correct for negative operands. Perhaps something like is safer:
use integer; $x = length("abc") % -10; $y = 3 % -10; print $x == $y ? "ok 6\n" : "# expected $y\, got $x\nnot ok 6\n";
Good point\, but I think we could do somewhat better.
Sarathy gsar@ActiveState.com
Migrated from rt.perl.org#1700 (status was 'resolved')
Searchable as RT1700$