| 1 |
package integer; |
| 2 |
|
| 3 |
our $VERSION = '1.00'; |
| 4 |
|
| 5 |
=head1 NAME |
| 6 |
|
| 7 |
integer - Perl pragma to use integer arithmetic instead of floating point |
| 8 |
|
| 9 |
=head1 SYNOPSIS |
| 10 |
|
| 11 |
use integer; |
| 12 |
$x = 10/3; |
| 13 |
# $x is now 3, not 3.33333333333333333 |
| 14 |
|
| 15 |
=head1 DESCRIPTION |
| 16 |
|
| 17 |
This tells the compiler to use integer operations from here to the end |
| 18 |
of the enclosing BLOCK. On many machines, this doesn't matter a great |
| 19 |
deal for most computations, but on those without floating point |
| 20 |
hardware, it can make a big difference in performance. |
| 21 |
|
| 22 |
Note that this only affects how most of the arithmetic and relational |
| 23 |
B<operators> handle their operands and results, and B<not> how all |
| 24 |
numbers everywhere are treated. Specifically, C<use integer;> has the |
| 25 |
effect that before computing the results of the arithmetic operators |
| 26 |
(+, -, *, /, %, +=, -=, *=, /=, %=, and unary minus), the comparison |
| 27 |
operators (<, <=, >, >=, ==, !=, <=>), and the bitwise operators (|, &, |
| 28 |
^, <<, >>, |=, &=, ^=, <<=, >>=), the operands have their fractional |
| 29 |
portions truncated (or floored), and the result will have its |
| 30 |
fractional portion truncated as well. In addition, the range of |
| 31 |
operands and results is restricted to that of familiar two's complement |
| 32 |
integers, i.e., -(2**31) .. (2**31-1) on 32-bit architectures, and |
| 33 |
-(2**63) .. (2**63-1) on 64-bit architectures. For example, this code |
| 34 |
|
| 35 |
use integer; |
| 36 |
$x = 5.8; |
| 37 |
$y = 2.5; |
| 38 |
$z = 2.7; |
| 39 |
$a = 2**31 - 1; # Largest positive integer on 32-bit machines |
| 40 |
$, = ", "; |
| 41 |
print $x, -$x, $x + $y, $x - $y, $x / $y, $x * $y, $y == $z, $a, $a + 1; |
| 42 |
|
| 43 |
will print: 5.8, -5, 7, 3, 2, 10, 1, 2147483647, -2147483648 |
| 44 |
|
| 45 |
Note that $x is still printed as having its true non-integer value of |
| 46 |
5.8 since it wasn't operated on. And note too the wrap-around from the |
| 47 |
largest positive integer to the largest negative one. Also, arguments |
| 48 |
passed to functions and the values returned by them are B<not> affected |
| 49 |
by C<use integer;>. E.g., |
| 50 |
|
| 51 |
srand(1.5); |
| 52 |
$, = ", "; |
| 53 |
print sin(.5), cos(.5), atan2(1,2), sqrt(2), rand(10); |
| 54 |
|
| 55 |
will give the same result with or without C<use integer;> The power |
| 56 |
operator C<**> is also not affected, so that 2 ** .5 is always the |
| 57 |
square root of 2. Now, it so happens that the pre- and post- increment |
| 58 |
and decrement operators, ++ and --, are not affected by C<use integer;> |
| 59 |
either. Some may rightly consider this to be a bug -- but at least it's |
| 60 |
a long-standing one. |
| 61 |
|
| 62 |
Finally, C<use integer;> also has an additional affect on the bitwise |
| 63 |
operators. Normally, the operands and results are treated as |
| 64 |
B<unsigned> integers, but with C<use integer;> the operands and results |
| 65 |
are B<signed>. This means, among other things, that ~0 is -1, and -2 & |
| 66 |
-5 is -6. |
| 67 |
|
| 68 |
Internally, native integer arithmetic (as provided by your C compiler) |
| 69 |
is used. This means that Perl's own semantics for arithmetic |
| 70 |
operations may not be preserved. One common source of trouble is the |
| 71 |
modulus of negative numbers, which Perl does one way, but your hardware |
| 72 |
may do another. |
| 73 |
|
| 74 |
% perl -le 'print (4 % -3)' |
| 75 |
-2 |
| 76 |
% perl -Minteger -le 'print (4 % -3)' |
| 77 |
1 |
| 78 |
|
| 79 |
See L<perlmodlib/"Pragmatic Modules">, L<perlop/"Integer Arithmetic"> |
| 80 |
|
| 81 |
=cut |
| 82 |
|
| 83 |
$integer::hint_bits = 0x1; |
| 84 |
|
| 85 |
sub import { |
| 86 |
$^H |= $integer::hint_bits; |
| 87 |
} |
| 88 |
|
| 89 |
sub unimport { |
| 90 |
$^H &= ~$integer::hint_bits; |
| 91 |
} |
| 92 |
|
| 93 |
1; |
