| Filename | /home/s1/perl5/perlbrew/perls/perl-5.22.1/lib/5.22.1/integer.pm |
| Statements | Executed 5 statements in 20µs |
| Calls | P | F | Exclusive Time |
Inclusive Time |
Subroutine |
|---|---|---|---|---|---|
| 2 | 2 | 1 | 6µs | 6µs | integer::import |
| 0 | 0 | 0 | 0s | 0s | integer::unimport |
| Line | State ments |
Time on line |
Calls | Time in subs |
Code |
|---|---|---|---|---|---|
| 1 | package integer; | ||||
| 2 | |||||
| 3 | 1 | 500ns | our $VERSION = '1.01'; | ||
| 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 | 1 | 200ns | $integer::hint_bits = 0x1; | ||
| 84 | |||||
| 85 | # spent 6µs within integer::import which was called 2 times, avg 3µs/call:
# once (3µs+0s) by DateTime::BEGIN@763 at line 763 of DateTime.pm
# once (3µs+0s) by DateTime::BEGIN@1925 at line 1925 of DateTime.pm | ||||
| 86 | 2 | 16µs | $^H |= $integer::hint_bits; | ||
| 87 | } | ||||
| 88 | |||||
| 89 | sub unimport { | ||||
| 90 | $^H &= ~$integer::hint_bits; | ||||
| 91 | } | ||||
| 92 | |||||
| 93 | 1 | 4µs | 1; |