develooper Front page | perl.perl5.porters | Postings from March 2001

Re: [ID 20010305.005] "use integer" doesn't make rand() return integers

Thread Previous | Thread Next
From:
John L. Allen
Date:
March 6, 2001 07:50
Subject:
Re: [ID 20010305.005] "use integer" doesn't make rand() return integers
Message ID:
Pine.SOL.3.91.1010306103113.9094A-100000@gateway.grumman.com


On Tue, 6 Mar 2001 abigail@foad.org wrote:

> On Mon, Mar 05, 2001 at 04:08:16PM -0500, John Peacock wrote:
> > Robert Spier wrote:
> > > 
> > > >>>>> "JP" == John Peacock <jpeacock@rowman.com> writes:
> > >     BUT - to be consistent with the current behaviour of use integer:
> > > perl -Minteger -le 'print 0+rand' # rinse and repeat
> > >     it is fine for it always to answer 0.  if you want bigger (random)
> > > integers, you must specify that.
> > > 
> > >     But I don't think the patch should be integrated anyway.  That's
> > > not what use integer is for.
> > > 
> > > -R
> > 
> > I agree that the patch should not go in; my point was I'm not even
> > sure that int(rand(10)) will not bias the random sequence returned by
> > rand().  When dealing with random numbers, I know enough to know only 
> > that I don't know enough!  ;~)
> 
> Well, if it doesn't than rand() is having a problem; and that doesn't
> have anything to do with 'use integer' or not. After all, if you cannot
> expect int(rand(10)) not to give 10% 0s, 10% 1s, .. 10% 9s, the values
> it returns are not uniformely distributed.
> 
> Having said that, having 'rand' returning integers when 'use integer'
> is in effect fits exactly in Perls DWIM nature.
> 
> Abigail

Being wholly dissatisfied with the vagueness of the integer.pm pod, I
came up with the appended patch.  Perhaps I tried to be too complete (and 
maybe failed at that), but what was there just wasn't enough.  Some of
this is also said in perlop.pod, but it doesn't hurt to be redundant, 
does it?  Or should all this be said in perlop.pod instead?

John.
------------
--- integer.pm.orig	Tue Mar  6 09:26:07 2001
+++ integer.pm	Tue Mar  6 10:28:55 2001
@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-integer - Perl pragma to compute arithmetic in integer instead of double
+integer - Perl pragma to use integer arithmetic instead of floating point
 
 =head1 SYNOPSIS
 
@@ -12,32 +12,55 @@
 
 =head1 DESCRIPTION
 
-This tells the compiler to use integer operations
-from here to the end of the enclosing BLOCK.  On many machines, 
-this doesn't matter a great deal for most computations, but on those 
-without floating point hardware, it can make a big difference.
-
-Note that this affects the operations, not the numbers.  If you run this
-code
+This tells the compiler to use integer operations from here to the end
+of the enclosing BLOCK.  On many machines, this doesn't matter a great
+deal for most computations, but on those without floating point
+hardware, it can make a big difference in performance.
+
+Note that this only affects how certain operators handle their operands
+and results, and not all numbers everywhere.  Specifically, C<use
+integer;> has the effect that before computing the result of X + Y, X -
+Y, X / Y, X * Y, X % Y, or -X (unary minus), the operands X and Y have
+their fractional portions truncated, and the result will have its
+fractional portion truncated as well.  For example, this code
 
     use integer;
-    $x = 1.5;
-    $y = $x + 1;
-    $z = -1.5;
-
-you'll be left with C<$x == 1.5>, C<$y == 2> and C<$z == -1>.  The $z
-case happens because unary C<-> counts as an operation.
-
-Native integer arithmetic (as provided by your C compiler) is used.
-This means that Perl's own semantics for arithmetic operations may
-not be preserved.  One common source of trouble is the modulus of
-negative numbers, which Perl does one way, but your hardware may do
-another.
-
-  % perl -le 'print (4 % -3)'
-  -2
-  % perl -Minteger -le 'print (4 % -3)'
-  1
+    $x = 5.8;
+    $y = 2.5;
+    $, = ", ";
+    print $x, -$x, $x + $y, $x - $y, $x / $y, $x * $y;
+
+will print:  5.8, -5, 7, 3, 2, 10
+
+Note that $x is still printed as having its true non-integer value of
+5.8 since it wasn't operated on.  Also, arguments passed to functions
+and the values returned by them are not affected by C<use integer;>.
+E.g.,
+
+    srand(1.5);
+    $, = ", ";
+    print sin(.5), cos(.5), atan2(1,2), sqrt(2), rand(10);
+
+will give the same result with or without C<use integer;>  The power
+operator C<**> is also not affected, so that 2 ** .5 is always the
+square root of 2.
+
+Finally, C<use integer;> also has an affect on the bitwise operators
+"&", "|", "^", "~", "<<", and ">>".  Normally, the operands and results
+are treated as unsigned integers, but with C<use integer;> the operands
+and results are signed.  This means, among other things, that ~0 is -1,
+and -2 & -5 is -6.
+
+Internally, native integer arithmetic (as provided by your C compiler)
+is used.  This means that Perl's own semantics for arithmetic
+operations may not be preserved.  One common source of trouble is the
+modulus of negative numbers, which Perl does one way, but your hardware
+may do another.
+
+    % perl -le 'print (4 % -3)'
+    -2
+    % perl -Minteger -le 'print (4 % -3)'
+    1
 
 See L<perlmod/Pragmatic Modules>.
 


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About