Commit | Line | Data |
a0d0e21e |
1 | package integer; |
2 | |
b75c8c73 |
3 | our $VERSION = '1.00'; |
4 | |
f06db76b |
5 | =head1 NAME |
6 | |
7 | integer - Perl pragma to compute arithmetic in integer instead of double |
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 | |
a3cb178b |
17 | This tells the compiler to use integer operations |
f06db76b |
18 | from here to the end of the enclosing BLOCK. On many machines, |
19 | this doesn't matter a great deal for most computations, but on those |
20 | without floating point hardware, it can make a big difference. |
21 | |
a3cb178b |
22 | Note that this affects the operations, not the numbers. If you run this |
23 | code |
24 | |
25 | use integer; |
26 | $x = 1.5; |
27 | $y = $x + 1; |
28 | $z = -1.5; |
29 | |
30 | you'll be left with C<$x == 1.5>, C<$y == 2> and C<$z == -1>. The $z |
31 | case happens because unary C<-> counts as an operation. |
32 | |
47f6b1df |
33 | Native integer arithmetic (as provided by your C compiler) is used. |
34 | This means that Perl's own semantics for arithmetic operations may |
35 | not be preserved. One common source of trouble is the modulus of |
36 | negative numbers, which Perl does one way, but your hardware may do |
37 | another. |
38 | |
39 | % perl -le 'print (4 % -3)' |
40 | -2 |
41 | % perl -Minteger -le 'print (4 % -3)' |
42 | 1 |
43 | |
f06db76b |
44 | See L<perlmod/Pragmatic Modules>. |
45 | |
46 | =cut |
47 | |
d5448623 |
48 | $integer::hint_bits = 0x1; |
49 | |
a0d0e21e |
50 | sub import { |
d5448623 |
51 | $^H |= $integer::hint_bits; |
a0d0e21e |
52 | } |
53 | |
54 | sub unimport { |
d5448623 |
55 | $^H &= ~$integer::hint_bits; |
a0d0e21e |
56 | } |
57 | |
58 | 1; |