two's compliment?

[187]

I'm hoping someone can clear up this little confusion here regarding
binary not's.

print unpack('H128', pack('N', ~4294966272));

This gives: 000003ff

Why is it on my TI86 I get FFFFFFFF000003FF. This seems more
(Commands: (not 4294966272)->Hex )

Which is correct? It seems more correct to me that the remaining bits be
flipped from the not operation (0 -> 1), but why do c/c++/perl/etc not
do this?

 

[Greg Bacon]

: I'm hoping someone can clear up this little confusion here regarding
: binary not's.
:
: print unpack('H128', pack('N', ~4294966272));
:
: This gives: 000003ff
:
: Why is it on my TI86 I get FFFFFFFF000003FF. This seems more
: (Commands: (not 4294966272)->Hex )
:
: Which is correct? It seems more correct to me that the remaining bits
: be flipped from the not operation (0 -> 1), but why do c/c++/perl/etc
: not do this?

The perlfunc manpage's documentation for pack has the following
excerpt:

n An unsigned short in "network" (big-endian) order.
N An unsigned long in "network" (big-endian) order.
v An unsigned short in "VAX" (little-endian) order.
V An unsigned long in "VAX" (little-endian) order.
(These 'shorts' and 'longs' are _exactly_ 16 bits and
_exactly_ 32 bits, respectively.)

You're expecting 64-bit quantities, so you have to work a little
harder:

$ cat try
#! /usr/local/bin/perl

use warnings;
use strict;

BEGIN {
use Config;

*bequad = eval($Config{use64bitint} ? <<'EOHave64' : <<'EOStub');
sub {
my $val = shift;

{
no warnings "portable"; # 64-bit hex constants

pack(N => ($val & 0xFFFFFFFF00000000) >> 32) .
pack(N => $val & 0x00000000FFFFFFFF);
}
}
EOHave64
sub { die "quads not supported in this perl" }
EOStub

}

my $bits = ~4294966272;
my $hex = unpack "H*", bequad $bits;

print $hex, "\n";

$ ./try
ffffffff000003ff

Hope this helps,
Greg

 

[Chris Mattern]

I'm hoping someone can clear up this little confusion here regarding
binary not's.

print unpack('H128', pack('N', ~4294966272));

This gives: 000003ff

Why is it on my TI86 I get FFFFFFFF000003FF. This seems more
(Commands: (not 4294966272)->Hex )

Which is correct?

The TI, of course.

It seems more correct to me that the remaining bits be
flipped from the not operation (0 -> 1), but why do c/c++/perl/etc not
do this?

Because there *aren't* any "remaining bits". The computer
you're working on has 4-byte integers, and you overflowed
it--the number is too big for your data model. The
TI, with 8-byte integers, was plenty big enough to
hold your number. Look up the documentation for pack
and unpack on how to specify 8-byte integers. You
wanted to say 'Q', not 'N' (and that'll only work if you
have 64-bit support).
--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"

 

[187]

"two's compliment" would be

he: You look nice!
she: You look nice too!

Maybe you meant "two's complement"?

And I would have sent this in email, but you didn't provide a valid
return address or any means to decrypt same. Shame on you!

Actually I never updated it, and for good reason. (Spam mainly.)

It's: bigal187 AT rx.eastcoasttfc.com

People like you not understanding Usenet operating procedure.

I really don't think you're correct here. Usenet is not about sending
email, it's about exchanging information *in* *news groups*. Standard
"operating procedure" has always been this, and everyone has the right
not ot display their true email. when ever I do, I get spammed, one way
or another. Since I stopped and changed my email, I don't get any.

Good day.

 

[187]

The TI, of course.


Because there *aren't* any "remaining bits". The computer
you're working on has 4-byte integers, and you overflowed
it--the number is too big for your data model. The
TI, with 8-byte integers, was plenty big enough to
hold your number. Look up the documentation for pack
and unpack on how to specify 8-byte integers. You
wanted to say 'Q', not 'N' (and that'll only work if you
have 64-bit support).

Thank you for your reply. I udnerstand how it became overloaded, but
then why does this happen?

print ~-31, "\n", ~30

Output:

30
4294967265

Why does the 2nd statement not return -31? Is it Perl not wanting to
return a signed number? This seems rather incorrect, mathimatically.
(Please corect me if I'm wrong.)

 

[187]

[Note: I meant UseNet has always bene abotu echanging information, but I
admit I may have impied *only* in new groups, which may be the core of
UseNet, but not the only way of exchanging information.]

For some version of "always". Mine apparently predates yours. You
speak like someone relatively new to Usenet, probably not coming until
the post-spam era.

In the pre-spam days, it was common courtesy to always include an
email address that worked, so that you could curse in private, but
bless in public. Nobody seems to have courtesy here any more.

Once again, I understand your point, but I think you've once again
mis-understood me. I have been around, I know *exactly* what you are
talking about But right now *is* the post-spam, not the pre-spam
era. Spam has forced many of us to munge our emails.

Also, I feel I didn't explain this correctly. I did have a valid email
address (munged) in my header of my original post, but had forgotten to
update it. It hadn't been a problem 'til your response. I have updated
my header now though, with a munged version of my current email.

So please don't get me wrong. I know you're a great and respected person
in the programming field, and I know you've taken part in writing some
good books (some reside on my shelf - camel/llama/alpaca(objects)...),
and I respect you too, and like you, I do miss the "good 'ol days" of
UseNet.

Bottom line though: If you can't reach me by demunging my header's email
address, just ask in a post and I'll be more than happy to provide the
correct one, as I did in my previous reply to you

 

[Joe Smith]

187 wrote:

Thank you for your reply. I udnerstand how it became overloaded, but

then why does this happen?

print ~-31, "\n", ~30

Output:

30
4294967265

Why does the 2nd statement not return -31? Is it Perl not wanting to
return a signed number? This seems rather incorrect, mathimatically.

In the first one, a signed 32-bit integer is treated as an unsigned
32-bit number, complemented, and displayed as an unsigned 32-bit number.
In the second one, a positive signed 32-bit integer is already in
the unsigned form, complemented, and displayed as an unsigned 32-bit
number. Both are consistent in converting the input argument to
a set of 32 bits and returning a set of 32 bits.
-Joe

 

[187]

187 wrote:

Thank you for your reply. I udnerstand how it became overloaded, but

In the first one, a signed 32-bit integer is treated as an unsigned
32-bit number, complemented, and displayed as an unsigned 32-bit
number. In the second one, a positive signed 32-bit integer is
already in
the unsigned form, complemented, and displayed as an unsigned 32-bit
number. Both are consistent in converting the input argument to
a set of 32 bits and returning a set of 32 bits.

Thank you, but why then do most calculators with a Not (TI's, like my
86) / Complement function return -31 for Not 30 ?

This difference is what really baking my noodle here!

 

[Anno Siegel]

Thank you, but why then do most calculators with a Not (TI's, like my
86) / Complement function return -31 for Not 30 ?

Why doesn't Perl behave exactly like your TI calculator? Probably
because TI calculators were among the few things that were not used
to model Perl's behavior. It's a design decision. The bit pattern
is the same for 4294967265 and -31. You get to chose what to print.

If you want Perl to show the same behavior as your TI calculator,
allow it to use the native integer representation for all numbers:

perl -le 'print ~-31, "\n", ~30'
30
4294967265

perl -Minteger -le 'print ~-31, "\n", ~30'
30
-31

This difference is what really baking my noodle here!

You seem to expect that for every arithmetic operation there is
one and only one result. But that's not true with computer
arithmetics. The internal representation (how many bits) and the
interpretation (as signed or unsigned numbers) introduce arbitrary
factors that can influence the outcome.

Anno

 

[187]

Why doesn't Perl behave exactly like your TI calculator? Probably
because TI calculators were among the few things that were not used
to model Perl's behavior. It's a design decision. The bit pattern
is the same for 4294967265 and -31. You get to chose what to print.

So do I correctly understand that this basically comes down to weatyher
or not the end result is a signed number or not?

If you want Perl to show the same behavior as your TI calculator,
allow it to use the native integer representation for all numbers:

perl -le 'print ~-31, "\n", ~30'
30
4294967265

perl -Minteger -le 'print ~-31, "\n", ~30'
30
-31

Addidtionaly I realized (as I finally got some on the long ride back
home this evening and for once am thinking clearly) that this code
(which identically works in C/C++)

printf("%d\n%d\n\n", ~-31, ~30);
printf("%u\n%u\n", ~-31, ~30);

30
-31

30
4294967265

Which furthur augments the signed/unsigned point.

You seem to expect that for every arithmetic operation there is
one and only one result. But that's not true with computer
arithmetics. The internal representation (how many bits) and the
interpretation (as signed or unsigned numbers) introduce arbitrary
factors that can influence the outcome.

Well, thats not exactly what I was getting at, which would be how to do
the equivilent of casting signed and unsigned forcibly like you would in
C/C++, and you've shown a way of doing that, thanks

And true, the way I used my example, a print statement, in that matter
it comes down to *how* you print this given value.