#### Do you have a question? Post it now! No Registration Necessary. Now with pictures!

## 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

Expectations aside. Reading that

“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

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:

#!/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 );

$ 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

*<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'

dad

FFFFFFFFFFFFF252

baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaad

Integer overflow in hexadecimal number at -e line 1, <> line 2.

0

#### Site Timeline

- » Anyone have a favorite reference manual?
- — Next thread in » PERL Discussions

- » Interesting ? wildcard bug in fileglob operator with Unicode file names.
- — Previous thread in » PERL Discussions

- » s suffix question
- — Newest thread in » PERL Discussions

- » Dell Battery Slice LED codes
- — The site's Newest Thread. Posted in » Laptop Computers Forum