# INVERSE question - Page 2

•  Subject
• Author
• Posted on

## Re: INVERSE question

Since there's a freak chance that someone actually is: People don't use
hexadecimal notation because they enjoy being difficult (except
sometimes) but because single hex digit can represent 16 different
values (0 - 15) and hence, can represent 4 value bits. This means that
the value of an 8 bit byte can always be expressed with 2 hex
digits. Consequently, when packing hex digits into bytes, if the number
isn't event, the trailing 4 bits will be zero. This means that 438 is
really 0x4380 and that it has to be written as 0438 if the leading four
bits are supposed to be zero.

## Re: INVERSE question

[...]

perl can also be forced into packing hex numbers right to left starting
from the 'end' of an array, as the bizarre human convention goes,

unpack('H*', ~reverse(pack('h*', scalar(reverse(\$x)))))

and in case all of this reversing of everything and reversing of that makes
someone's head spin, another option would be

unpack("H*", ~pack("H*", 0 x (length(\$x) & 1) . \$x))

Wrap this in

substr(..., -length(\$x))

in case you're hardcore opposed to even numbers of 4-tuples.

## Re: INVERSE question

On 10.07.15 11:25, Rainer Weikusat wrote:

“The pack and unpack functions can also deal with hex numbers and
the bit operators also work with binary strings of an arbitraty
length,”

and then that

“\$x =~ tr/0123456789ABCDEF/FEDCBA9876543210/;

“can also be expressed as

“\$x = unpack('H*', ~pack('H*', \$x));”

is a bit of a situation shifter, and in this sense wrong:
for pack/unpack, strings of hex digits would obviously(?)
need to have a suitable length. But not for tr///. The
assumption of suitable length had not been originally present,
AFAICT, it is necessary for pack/unpack only, and I'm not
sure the need is at all obvious.

## Re: INVERSE question

The original question asked for 16-bit values. That's something
different than 'arbitrarily long strings of hex digits' and 'an
arbitrarily long sequence of bytes represented as sequence of hex
digits' is yet something different. All three approaches are worth
knowing about and someone who sees the difference and doesn't consider
it self-evident ought to state it clearly.

## Re: INVERSE question

rweikusat@mobileactivedefense.com says...

Its not a bug, its a feature you damn ignoramous...  A byte is 2 hex digits, so even though I
posted this as another solution that can handle hex numbers of "arbitrary" size, what I
really meant was it will work as long as they are sizes that fit into bytes!  If you don't
see how that is the same thing or at least is the only useful way one could use such a
program, then you sir are ignorant.  Sheesh, these people I have to deal with, don't even
know how many bits are in a byte...

John Black

## Re: INVERSE question

It's something which ought to have been obvious from the Perl
documentation alone, and which anybody also ought to have picked up from
the additional description I gave: It's neither a bug nor a feature but
a property of the pack/ unpack and of the fact that computers don't work
with 'half bytes'.

## Re: INVERSE question

On 07/09/2015 09:12 AM, Rainer Weikusat wrote:

<code>
#!/usr/bin/perl

# \$x =~ tr/0123456789ABCDEF/FEDCBA9876543210/;

print "Enter a hex number: ";
\$A = <STDIN>;
chomp ( \$A );
\$A = uc ( \$A );

\$B =  hex ( \$A );
\$C= ~  \$B;

printf (  "The inverse of %s = 0x%X is 0x%X\n", \$A, \$B, \$C );
</code>

\$ perl HexInverse.pl
Enter a hex number: 4f
The inverse of 4F = 0x4F is 0xFFFFFFFFFFFFFFB0

\$ perl HexInverse.pl
Enter a hex number: 86
The inverse of 86 = 0x86 is 0xFFFFFFFFFFFFFF79

## Re: INVERSE question

I didn't write that, I just quoted it. It came from John Black.

The point of the exercise was to be able to work with hex numbers which
are larger than what fits into an integer, cf

[rw@doppelsaurus]/tmp#perl -pe 's/.*/sprintf("%X", ~hex(\$_))/e'
FFFFFFFFFFFFF252
Integer overflow in hexadecimal number at -e line 1, <> line 2.
0

## Re: INVERSE question

On 07/09/2015 08:37 AM, John Black wrote:

THANK YOU!

I especially love the validity check.  I find that from 50 to 90%
of what I write no-a-days is making sure that input/data is
sane/rational.