| 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; |