Query: perlfaq4
OS: suse
Section: 1
Format: Original Unix Latex Style Formatted with HTML and a Horizontal Scroll Bar
PERLFAQ4(1) Perl Programmers Reference Guide PERLFAQ4(1)NAMEperlfaq4 - Data ManipulationDESCRIPTIONThis section of the FAQ answers questions related to manipulating numbers, dates, strings, arrays, hashes, and miscellaneous data issues. Data: Numbers Why am I getting long decimals (eg, 19.9499999999999) instead of the numbers I should be getting (eg, 19.95)? Internally, your computer represents floating-point numbers in binary. Digital (as in powers of two) computers cannot store all numbers exactly. Some real numbers lose precision in the process. This is a problem with how computers store numbers and affects all computer languages, not just Perl. perlnumber shows the gory details of number representations and conversions. To limit the number of decimal places in your numbers, you can use the "printf" or "sprintf" function. See the "Floating Point Arithmetic" for more details. printf "%.2f", 10/3; my $number = sprintf "%.2f", 10/3; Why is int() broken? Your "int()" is most probably working just fine. It's the numbers that aren't quite what you think. First, see the answer to "Why am I getting long decimals (eg, 19.9499999999999) instead of the numbers I should be getting (eg, 19.95)?". For example, this print int(0.6/0.2-2), " "; will in most computers print 0, not 1, because even such simple numbers as 0.6 and 0.2 cannot be presented exactly by floating-point numbers. What you think in the above as 'three' is really more like 2.9999999999999995559. Why isn't my octal data interpreted correctly? (contributed by brian d foy) You're probably trying to convert a string to a number, which Perl only converts as a decimal number. When Perl converts a string to a number, it ignores leading spaces and zeroes, then assumes the rest of the digits are in base 10: my $string = '0644'; print $string + 0; # prints 644 print $string + 44; # prints 688, certainly not octal! This problem usually involves one of the Perl built-ins that has the same name a Unix command that uses octal numbers as arguments on the command line. In this example, "chmod" on the command line knows that its first argument is octal because that's what it does: %prompt> chmod 644 file If you want to use the same literal digits(644) in Perl, you have to tell Perl to treat them as octal numbers either by prefixing the digits with a 0 or using "oct": chmod( 0644, $file); # right, has leading zero chmod( oct(644), $file ); # also correct The problem comes in when you take your numbers from something that Perl thinks is a string, such as a command line argument in @ARGV: chmod( $ARGV[0], $file); # wrong, even if "0644" chmod( oct($ARGV[0]), $file ); # correct, treat string as octal You can always check the value you're using by printing it in octal notation to ensure it matches what you think it should be. Print it in octal and decimal format: printf "0%o %d", $number, $number; Does Perl have a round() function? What about ceil() and floor()? Trig functions? Remember that "int()" merely truncates toward 0. For rounding to a certain number of digits, "sprintf()" or "printf()" is usually the easiest route. printf("%.3f", 3.1415926535); # prints 3.142 The "POSIX" module (part of the standard Perl distribution) implements "ceil()", "floor()", and a number of other mathematical and trigonometric functions. use POSIX; $ceil = ceil(3.5); # 4 $floor = floor(3.5); # 3 In 5.000 to 5.003 perls, trigonometry was done in the "Math::Complex" module. With 5.004, the "Math::Trig" module (part of the standard Perl distribution) implements the trigonometric functions. Internally it uses the "Math::Complex" module and some functions can break out from the real axis into the complex plane, for example the inverse sine of 2. Rounding in financial applications can have serious implications, and the rounding method used should be specified precisely. In these cases, it probably pays not to trust whichever system rounding is being used by Perl, but to instead implement the rounding function you need yourself. To see why, notice how you'll still have an issue on half-way-point alternation: for ($i = 0; $i < 1.01; $i += 0.05) { printf "%.1f ",$i} 0.0 0.1 0.1 0.2 0.2 0.2 0.3 0.3 0.4 0.4 0.5 0.5 0.6 0.7 0.7 0.8 0.8 0.9 0.9 1.0 1.0 Don't blame Perl. It's the same as in C. IEEE says we have to do this. Perl numbers whose absolute values are integers under 2**31 (on 32 bit machines) will work pretty much like mathematical integers. Other numbers are not guaranteed. How do I convert between numeric representations/bases/radixes? As always with Perl there is more than one way to do it. Below are a few examples of approaches to making common conversions between number representations. This is intended to be representational rather than exhaustive. Some of the examples later in perlfaq4 use the "Bit::Vector" module from CPAN. The reason you might choose "Bit::Vector" over the perl built in functions is that it works with numbers of ANY size, that it is optimized for speed on some operations, and for at least some programmers the notation might be familiar. How do I convert hexadecimal into decimal Using perl's built in conversion of "0x" notation: $dec = 0xDEADBEEF; Using the "hex" function: $dec = hex("DEADBEEF"); Using "pack": $dec = unpack("N", pack("H8", substr("0" x 8 . "DEADBEEF", -8))); Using the CPAN module "Bit::Vector": use Bit::Vector; $vec = Bit::Vector->new_Hex(32, "DEADBEEF"); $dec = $vec->to_Dec(); How do I convert from decimal to hexadecimal Using "sprintf": $hex = sprintf("%X", 3735928559); # upper case A-F $hex = sprintf("%x", 3735928559); # lower case a-f Using "unpack": $hex = unpack("H*", pack("N", 3735928559)); Using "Bit::Vector": use Bit::Vector; $vec = Bit::Vector->new_Dec(32, -559038737); $hex = $vec->to_Hex(); And "Bit::Vector" supports odd bit counts: use Bit::Vector; $vec = Bit::Vector->new_Dec(33, 3735928559); $vec->Resize(32); # suppress leading 0 if unwanted $hex = $vec->to_Hex(); How do I convert from octal to decimal Using Perl's built in conversion of numbers with leading zeros: $dec = 033653337357; # note the leading 0! Using the "oct" function: $dec = oct("33653337357"); Using "Bit::Vector": use Bit::Vector; $vec = Bit::Vector->new(32); $vec->Chunk_List_Store(3, split(//, reverse "33653337357")); $dec = $vec->to_Dec(); How do I convert from decimal to octal Using "sprintf": $oct = sprintf("%o", 3735928559); Using "Bit::Vector": use Bit::Vector; $vec = Bit::Vector->new_Dec(32, -559038737); $oct = reverse join('', $vec->Chunk_List_Read(3)); How do I convert from binary to decimal Perl 5.6 lets you write binary numbers directly with the "0b" notation: $number = 0b10110110; Using "oct": my $input = "10110110"; $decimal = oct( "0b$input" ); Using "pack" and "ord": $decimal = ord(pack('B8', '10110110')); Using "pack" and "unpack" for larger strings: $int = unpack("N", pack("B32", substr("0" x 32 . "11110101011011011111011101111", -32))); $dec = sprintf("%d", $int); # substr() is used to left pad a 32 character string with zeros. Using "Bit::Vector": $vec = Bit::Vector->new_Bin(32, "11011110101011011011111011101111"); $dec = $vec->to_Dec(); How do I convert from decimal to binary Using "sprintf" (perl 5.6+): $bin = sprintf("%b", 3735928559); Using "unpack": $bin = unpack("B*", pack("N", 3735928559)); Using "Bit::Vector": use Bit::Vector; $vec = Bit::Vector->new_Dec(32, -559038737); $bin = $vec->to_Bin(); The remaining transformations (e.g. hex -> oct, bin -> hex, etc.) are left as an exercise to the inclined reader. Why doesn't & work the way I want it to? The behavior of binary arithmetic operators depends on whether they're used on numbers or strings. The operators treat a string as a series of bits and work with that (the string "3" is the bit pattern 00110011). The operators work with the binary form of a number (the number 3 is treated as the bit pattern 00000011). So, saying "11 & 3" performs the "and" operation on numbers (yielding 3). Saying "11" & "3" performs the "and" operation on strings (yielding "1"). Most problems with "&" and "|" arise because the programmer thinks they have a number but really it's a string. The rest arise because the programmer says: if ("