tried unpack same result :( | [reply] |

The basic problem appears to be that you have a 32 bit machine and you need a bigger integer than can be represented in 32 bits.
If you have 4 bits, the biggest unsigned number that
you can represent is with all 4 bits "on", is, "1111", or
15 in decimal, 2**4-1=15, or 'F'. 0123456789ABCDEF is all
16 possibilities with 4 bits.
The biggest unsigned 32 bit number is 2**32-1= 4,294,967,295.
The normal convention for representing a "signed" number is what
is called 2's complement arithmetic. If you have 4 bits and have
say 0001, to get "-1", you complement (reverse) all bits and then add
one. 1110+1=1111. Now we come to the interpretation of whether "1111"
means "15" or "-1". Basically the most significant bit becomes the
"sign bit". 0111 with 4 bits is the max positive number or 2**3-1=7.
1000 is the max negative number which weirdly enough is -8.
So if you have 32 bits as signed 2's complement, you get
"0111 1111 1111 1111 1111 1111 1111 1111" or 2,147,483,647 as the
max positive number and -2,147,483,648 as the max negative number.
I think a Perl float uses more than 32 bits for the "mantissa". I think it maybe
as many as 53 bits. I'm not sure. I think the "safest" way is to use these
big int modules. The 32 bit integer to think about is 2 billion. When you get to that size integer number, things can get more complicated.
123,143,230,627 is a lot bigger than 2,147,483,647 and hence the problems.
| [reply] |

Comment onRe: long integer to hexadecimal conversion