Why is minus one (-1) equal to true in VB again?

[Ruffin Bailey]

I coulda sworn I was given an explanation during an AppDev class years
ago for VB6, but don't recall the answer. Why is it that -1 is True
in Visual Basic (and now VB.NET)? Bit flags seem like they should
always be 0 or 1 to me... (not that I haven't used VB long enough by
now to know better).

Sorry to pester, but "why is -1 = true?" is a difficult thing to
Google!

Ruffin Bailey

[One Handed Man \( OHM - Terry Burns \)]

No, it is stored as a +1 one the stack.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
"Herfried K. Wagner [MVP]" <hi************ ***@gmx.at> wrote in message
news:2j******** *****@uni-berlin.de...

* "One Handed Man \( OHM - Terry Burns \)" <news.microsoft .com> scripsit:

My point was that true is not stored as -1, rather that it is stored
as 1.

It's stored as -1 if you do a 'Not False'.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Ruffin Bailey]

"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message news:<#T******* *******@TK2MSFT NGP12.phx.gbl>. ..

Additionally, by storing the Boolean value as all 1's or all 0's, you get an
additional performance gain when dealing with IO, as you can ignore the Byte
Ordering (Little/Middle/Big Endean). 1111 = 1111 forward or backward.
What the heck is middle endian? ;^) The other two, being a Mac user
when I'm not at work, have pretty clear meanings.

But this makes some sense for why things are -1 and not 1 or (as you
point out below) -0. False is "everything off" and True is "every
switch on". And 11111111 = -1 -- but it's not -1 in signed Integers,
which is confusing. That'd be 10000001, right?
IF you did have a 1 Bit signed integer type, if the value was not 0, it would
be -1 (or -0, but that's a discussion for another day)
Actually that makes sense and we can dispense with the new discussion!
;^) That's part of my original wondering about why it works as it
does. 10000000 in a signed byte would be "negative 0000000". I've
done just enough assembly
(http://mywebpages.comcast.net/rufbo1/mactari/mact.html) to have a
decent handle on how the bits work. It would have made sense to me to
have "official True" be 10000000 (a quick rol to check) or 00000001
(1=1), but 10000001 (signed -1) didn't make much sense at all.

Now, again, 11111111 is -1 in unsigned bytes, right? That makes some
sense as True.

Though admittedly I'm starting to wonder if I haven't got negative
signed byte expressions off in my head, as everyone seems to accept
11111111 (realizing I'm simplifying everything using one byte instead
of 32 bit fun) as -1 *signed*. ???
A Boolean evaluation of an expression is actually a double negative.
If an expression does not evaluate to False(0), then it must be True. So all non
zero values are True.

That's been mentioned a few times, and immediately after posting it
occurred to me to check and see what CBool(1) gave me (True). But why
CInt(True) gave me -1 for "official True" was a mystery. I think the
"all bits True in the byte" makes the most sense. Whether that's -1
in signed- or unsigned-land, I'll straighten out in my head later!

Thanks everyone for the posts. Feel free to lambast my relatively
weak grasping of the situation! If I didn't have so many bad habits
already, the "Turn on Option Strict" post my be the best suggestion of
them all.

Ruffin Bailey

[Ruffin Bailey]

"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message news:<#T******* *******@TK2MSFT NGP12.phx.gbl>. ..

Additionally, by storing the Boolean value as all 1's or all 0's, you get an
additional performance gain when dealing with IO, as you can ignore the Byte
Ordering (Little/Middle/Big Endean). 1111 = 1111 forward or backward.
What the heck is middle endian? ;^) The other two, being a Mac user
when I'm not at work, have pretty clear meanings.

But this makes some sense for why things are -1 and not 1 or (as you
point out below) -0. False is "everything off" and True is "every
switch on". And 11111111 = -1 -- but it's not -1 in signed Integers,
which is confusing. That'd be 10000001, right?
IF you did have a 1 Bit signed integer type, if the value was not 0, it would
be -1 (or -0, but that's a discussion for another day)
Actually that makes sense and we can dispense with the new discussion!
;^) That's part of my original wondering about why it works as it
does. 10000000 in a signed byte would be "negative 0000000". I've
done just enough assembly
(http://mywebpages.comcast.net/rufbo1/mactari/mact.html) to have a
decent handle on how the bits work. It would have made sense to me to
have "official True" be 10000000 (a quick rol to check) or 00000001
(1=1), but 10000001 (signed -1) didn't make much sense at all.

Now, again, 11111111 is -1 in unsigned bytes, right? That makes some
sense as True.

Though admittedly I'm starting to wonder if I haven't got negative
signed byte expressions off in my head, as everyone seems to accept
11111111 (realizing I'm simplifying everything using one byte instead
of 32 bit fun) as -1 *signed*. ???
A Boolean evaluation of an expression is actually a double negative.
If an expression does not evaluate to False(0), then it must be True. So all non
zero values are True.

That's been mentioned a few times, and immediately after posting it
occurred to me to check and see what CBool(1) gave me (True). But why
CInt(True) gave me -1 for "official True" was a mystery. I think the
"all bits True in the byte" makes the most sense. Whether that's -1
in signed- or unsigned-land, I'll straighten out in my head later!

Thanks everyone for the posts. Feel free to lambast my relatively
weak grasping of the situation! If I didn't have so many bad habits
already, the "Turn on Option Strict" post my be the best suggestion of
them all.

Ruffin Bailey

[Cablewizard]

Ruffin,

Middle Endian is when you fiddle with the byte ordering in the Word.
1-2-3-4 Big Endian
4-3-2-1 Little Endian
3-4-1-2 / 2-1-3-4 Middle Endian

Take a look at:
http://en.wikipedia.org/wiki/Endianness

This works best on 16Bit computers living in the 32Bit world.
In fact, some IO in Windows still works this way.

Your confusion on the representation of Bits and why -1=11111111 and not
10000001 is because you are thinking as a human :)
Binary math is simplified if you use "Two's Complement" representation of the
binary for negative numbers.
That is how computers like to do it.
This would make the representation backwards from what you would think.
Basically, take a positive representation, flip the bits, then add 1.
Take the value +1 = 0000001
Flip the bits to make negative = 1111110
Add 1 = 11111111

So 11111111 = -1 in a Signed Byte
In an Unsigned Byte, it would be 255

Hope this helps to clear things up a little.

Gerald
"Ruffin Bailey" <ka****@mailina tor.com> wrote in message
news:fd******** *************** ***@posting.goo gle.com...

"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message

news:<#T******* *******@TK2MSFT NGP12.phx.gbl>. ..

Additionally, by storing the Boolean value as all 1's or all 0's, you get an
additional performance gain when dealing with IO, as you can ignore the Byte
Ordering (Little/Middle/Big Endean). 1111 = 1111 forward or backward.

What the heck is middle endian? ;^) The other two, being a Mac user
when I'm not at work, have pretty clear meanings.

But this makes some sense for why things are -1 and not 1 or (as you
point out below) -0. False is "everything off" and True is "every
switch on". And 11111111 = -1 -- but it's not -1 in signed Integers,
which is confusing. That'd be 10000001, right?

IF you did have a 1 Bit signed integer type, if the value was not 0, it would be -1 (or -0, but that's a discussion for another day)

Actually that makes sense and we can dispense with the new discussion!
;^) That's part of my original wondering about why it works as it
does. 10000000 in a signed byte would be "negative 0000000". I've
done just enough assembly
(http://mywebpages.comcast.net/rufbo1/mactari/mact.html) to have a
decent handle on how the bits work. It would have made sense to me to
have "official True" be 10000000 (a quick rol to check) or 00000001
(1=1), but 10000001 (signed -1) didn't make much sense at all.

Now, again, 11111111 is -1 in unsigned bytes, right? That makes some
sense as True.

Though admittedly I'm starting to wonder if I haven't got negative
signed byte expressions off in my head, as everyone seems to accept
11111111 (realizing I'm simplifying everything using one byte instead
of 32 bit fun) as -1 *signed*. ???

A Boolean evaluation of an expression is actually a double negative.
If an expression does not evaluate to False(0), then it must be True. So all non zero values are True.

That's been mentioned a few times, and immediately after posting it
occurred to me to check and see what CBool(1) gave me (True). But why
CInt(True) gave me -1 for "official True" was a mystery. I think the
"all bits True in the byte" makes the most sense. Whether that's -1
in signed- or unsigned-land, I'll straighten out in my head later!

Thanks everyone for the posts. Feel free to lambast my relatively
weak grasping of the situation! If I didn't have so many bad habits
already, the "Turn on Option Strict" post my be the best suggestion of
them all.

Ruffin Bailey

[Cablewizard]

As a side note, this is what makes the topic of -0 interesting.
If you do some research, you will see that when using two's complement, you get
a couple of interesting exceptions to the rule that would seemingly break
things. But when they are resolved, they actually end up being what you wanted
in the first place.
-0 and +128 would be of significant note.
This is why a signed byte ranges from -128 to +127.
And not +- 127 or +- 128.

Gerald

"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:eq******** ******@TK2MSFTN GP10.phx.gbl...

Ruffin,

Middle Endian is when you fiddle with the byte ordering in the Word.
1-2-3-4 Big Endian
4-3-2-1 Little Endian
3-4-1-2 / 2-1-3-4 Middle Endian

Take a look at:
http://en.wikipedia.org/wiki/Endianness

This works best on 16Bit computers living in the 32Bit world.
In fact, some IO in Windows still works this way.

Your confusion on the representation of Bits and why -1=11111111 and not
10000001 is because you are thinking as a human :)
Binary math is simplified if you use "Two's Complement" representation of the
binary for negative numbers.
That is how computers like to do it.
This would make the representation backwards from what you would think.
Basically, take a positive representation, flip the bits, then add 1.
Take the value +1 = 0000001
Flip the bits to make negative = 1111110
Add 1 = 11111111

So 11111111 = -1 in a Signed Byte
In an Unsigned Byte, it would be 255

Hope this helps to clear things up a little.

Gerald
"Ruffin Bailey" <ka****@mailina tor.com> wrote in message
news:fd******** *************** ***@posting.goo gle.com...

"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message news:<#T******* *******@TK2MSFT NGP12.phx.gbl>. ..

Additionally, by storing the Boolean value as all 1's or all 0's, you get an additional performance gain when dealing with IO, as you can ignore the Byte Ordering (Little/Middle/Big Endean). 1111 = 1111 forward or backward.

What the heck is middle endian? ;^) The other two, being a Mac user
when I'm not at work, have pretty clear meanings.

But this makes some sense for why things are -1 and not 1 or (as you
point out below) -0. False is "everything off" and True is "every
switch on". And 11111111 = -1 -- but it's not -1 in signed Integers,
which is confusing. That'd be 10000001, right?

IF you did have a 1 Bit signed integer type, if the value was not 0, it would be -1 (or -0, but that's a discussion for another day)

Actually that makes sense and we can dispense with the new discussion!
;^) That's part of my original wondering about why it works as it
does. 10000000 in a signed byte would be "negative 0000000". I've
done just enough assembly
(http://mywebpages.comcast.net/rufbo1/mactari/mact.html) to have a
decent handle on how the bits work. It would have made sense to me to
have "official True" be 10000000 (a quick rol to check) or 00000001
(1=1), but 10000001 (signed -1) didn't make much sense at all.

Now, again, 11111111 is -1 in unsigned bytes, right? That makes some
sense as True.

Though admittedly I'm starting to wonder if I haven't got negative
signed byte expressions off in my head, as everyone seems to accept
11111111 (realizing I'm simplifying everything using one byte instead
of 32 bit fun) as -1 *signed*. ???

A Boolean evaluation of an expression is actually a double negative.
If an expression does not evaluate to False(0), then it must be True. So

all non zero values are True.

That's been mentioned a few times, and immediately after posting it
occurred to me to check and see what CBool(1) gave me (True). But why
CInt(True) gave me -1 for "official True" was a mystery. I think the
"all bits True in the byte" makes the most sense. Whether that's -1
in signed- or unsigned-land, I'll straighten out in my head later!

Thanks everyone for the posts. Feel free to lambast my relatively
weak grasping of the situation! If I didn't have so many bad habits
already, the "Turn on Option Strict" post my be the best suggestion of
them all.

Ruffin Bailey

[One Handed Man \( OHM - Terry Burns \)]

All of this is a bit superfluous really. I have discovered that the
compiler stores a +1 for True on the stack for a boolean type 'True' and 0
for a Boolean Type 'False'
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

As a side note, this is what makes the topic of -0 interesting.
If you do some research, you will see that when using two's complement, you get a couple of interesting exceptions to the rule that would seemingly break
things. But when they are resolved, they actually end up being what you wanted in the first place.
-0 and +128 would be of significant note.
This is why a signed byte ranges from -128 to +127.
And not +- 127 or +- 128.

Gerald

"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:eq******** ******@TK2MSFTN GP10.phx.gbl...

Ruffin,

Middle Endian is when you fiddle with the byte ordering in the Word.
1-2-3-4 Big Endian
4-3-2-1 Little Endian
3-4-1-2 / 2-1-3-4 Middle Endian

Take a look at:
http://en.wikipedia.org/wiki/Endianness

This works best on 16Bit computers living in the 32Bit world.
In fact, some IO in Windows still works this way.

Your confusion on the representation of Bits and why -1=11111111 and not
10000001 is because you are thinking as a human :)
Binary math is simplified if you use "Two's Complement" representation of the

binary for negative numbers.
That is how computers like to do it.
This would make the representation backwards from what you would think.
Basically, take a positive representation, flip the bits, then add 1.
Take the value +1 = 0000001
Flip the bits to make negative = 1111110
Add 1 = 11111111

So 11111111 = -1 in a Signed Byte
In an Unsigned Byte, it would be 255

Hope this helps to clear things up a little.

Gerald
"Ruffin Bailey" <ka****@mailina tor.com> wrote in message
news:fd******** *************** ***@posting.goo gle.com...

"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message news:<#T******* *******@TK2MSFT NGP12.phx.gbl>. ..

> Additionally, by storing the Boolean value as all 1's or all 0's, you get an > additional performance gain when dealing with IO, as you can ignore

the

Byte > Ordering (Little/Middle/Big Endean). 1111 = 1111 forward or

backward.
What the heck is middle endian? ;^) The other two, being a Mac user
when I'm not at work, have pretty clear meanings.

But this makes some sense for why things are -1 and not 1 or (as you
point out below) -0. False is "everything off" and True is "every
switch on". And 11111111 = -1 -- but it's not -1 in signed Integers,
which is confusing. That'd be 10000001, right?

> IF you did have a 1 Bit signed integer type, if the value was not 0,

it would

> be -1 (or -0, but that's a discussion for another day)

Actually that makes sense and we can dispense with the new discussion!
;^) That's part of my original wondering about why it works as it
does. 10000000 in a signed byte would be "negative 0000000". I've
done just enough assembly
(http://mywebpages.comcast.net/rufbo1/mactari/mact.html) to have a
decent handle on how the bits work. It would have made sense to me to
have "official True" be 10000000 (a quick rol to check) or 00000001
(1=1), but 10000001 (signed -1) didn't make much sense at all.

Now, again, 11111111 is -1 in unsigned bytes, right? That makes some
sense as True.

Though admittedly I'm starting to wonder if I haven't got negative
signed byte expressions off in my head, as everyone seems to accept
11111111 (realizing I'm simplifying everything using one byte instead
of 32 bit fun) as -1 *signed*. ???

> A Boolean evaluation of an expression is actually a double negative.
> If an expression does not evaluate to False(0), then it must be

True. So all

non

> zero values are True.

That's been mentioned a few times, and immediately after posting it
occurred to me to check and see what CBool(1) gave me (True). But why
CInt(True) gave me -1 for "official True" was a mystery. I think the
"all bits True in the byte" makes the most sense. Whether that's -1
in signed- or unsigned-land, I'll straighten out in my head later!

Thanks everyone for the posts. Feel free to lambast my relatively
weak grasping of the situation! If I didn't have so many bad habits
already, the "Turn on Option Strict" post my be the best suggestion of
them all.

Ruffin Bailey

[Cablewizard]

Agreed. I haven't investigated the actual implementation in dotNet or the other
various languages.
This has become more about the mechanics of it all as opposed to the
implementation.
Although if one was to ask me to guess what the implementation would have been,
my guess would not have been +1.
So I do find the actual implementation to be interesting.

In the end, I think Greg deserves the vote for the "best" answer.
FALSE = 0
TRUE = !FALSE

But as it turns out, how you actually implement that can vary.

Gerald
There are 10 kinds of people in the world.
Those that understand Binary, and those that do not.
(oldie but goodie, and appropriate here)

"One Handed Man ( OHM - Terry Burns )" <news.microsoft .com> wrote in message
news:OX******** ******@TK2MSFTN GP12.phx.gbl...

All of this is a bit superfluous really. I have discovered that the
compiler stores a +1 for True on the stack for a boolean type 'True' and 0
for a Boolean Type 'False'
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

As a side note, this is what makes the topic of -0 interesting.
If you do some research, you will see that when using two's complement,

you get

a couple of interesting exceptions to the rule that would seemingly break
things. But when they are resolved, they actually end up being what you

wanted

in the first place.
-0 and +128 would be of significant note.
This is why a signed byte ranges from -128 to +127.
And not +- 127 or +- 128.

Gerald

"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:eq******** ******@TK2MSFTN GP10.phx.gbl...

Ruffin,

Middle Endian is when you fiddle with the byte ordering in the Word.
1-2-3-4 Big Endian
4-3-2-1 Little Endian
3-4-1-2 / 2-1-3-4 Middle Endian

Take a look at:
http://en.wikipedia.org/wiki/Endianness

This works best on 16Bit computers living in the 32Bit world.
In fact, some IO in Windows still works this way.

Your confusion on the representation of Bits and why -1=11111111 and not
10000001 is because you are thinking as a human :)
Binary math is simplified if you use "Two's Complement" representation of the binary for negative numbers.
That is how computers like to do it.
This would make the representation backwards from what you would think.
Basically, take a positive representation, flip the bits, then add 1.
Take the value +1 = 0000001
Flip the bits to make negative = 1111110
Add 1 = 11111111

So 11111111 = -1 in a Signed Byte
In an Unsigned Byte, it would be 255

Hope this helps to clear things up a little.

Gerald
"Ruffin Bailey" <ka****@mailina tor.com> wrote in message
news:fd******** *************** ***@posting.goo gle.com...
> "Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:<#T******* *******@TK2MSFT NGP12.phx.gbl>. ..
> > Additionally, by storing the Boolean value as all 1's or all 0's, you get

an

> > additional performance gain when dealing with IO, as you can ignore

the

Byte

> > Ordering (Little/Middle/Big Endean). 1111 = 1111 forward or

backward. >
> What the heck is middle endian? ;^) The other two, being a Mac user
> when I'm not at work, have pretty clear meanings.
>
> But this makes some sense for why things are -1 and not 1 or (as you
> point out below) -0. False is "everything off" and True is "every
> switch on". And 11111111 = -1 -- but it's not -1 in signed Integers,
> which is confusing. That'd be 10000001, right?
>
> > IF you did have a 1 Bit signed integer type, if the value was not 0, it would
> > be -1 (or -0, but that's a discussion for another day)
>
> Actually that makes sense and we can dispense with the new discussion!
> ;^) That's part of my original wondering about why it works as it
> does. 10000000 in a signed byte would be "negative 0000000". I've
> done just enough assembly
> (http://mywebpages.comcast.net/rufbo1/mactari/mact.html) to have a
> decent handle on how the bits work. It would have made sense to me to
> have "official True" be 10000000 (a quick rol to check) or 00000001
> (1=1), but 10000001 (signed -1) didn't make much sense at all.
>
> Now, again, 11111111 is -1 in unsigned bytes, right? That makes some
> sense as True.
>
> Though admittedly I'm starting to wonder if I haven't got negative
> signed byte expressions off in my head, as everyone seems to accept
> 11111111 (realizing I'm simplifying everything using one byte instead
> of 32 bit fun) as -1 *signed*. ???
>
> > A Boolean evaluation of an expression is actually a double negative.
> > If an expression does not evaluate to False(0), then it must be

True. So

all

non
> > zero values are True.
>
> That's been mentioned a few times, and immediately after posting it
> occurred to me to check and see what CBool(1) gave me (True). But why
> CInt(True) gave me -1 for "official True" was a mystery. I think the
> "all bits True in the byte" makes the most sense. Whether that's -1
> in signed- or unsigned-land, I'll straighten out in my head later!
>
> Thanks everyone for the posts. Feel free to lambast my relatively
> weak grasping of the situation! If I didn't have so many bad habits
> already, the "Turn on Option Strict" post my be the best suggestion of
> them all.
>
> Ruffin Bailey

[Greg Young]

I just miss using while(3) in C :(
"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

Agreed. I haven't investigated the actual implementation in dotNet or the other various languages.
This has become more about the mechanics of it all as opposed to the
implementation.
Although if one was to ask me to guess what the implementation would have been, my guess would not have been +1.
So I do find the actual implementation to be interesting.

In the end, I think Greg deserves the vote for the "best" answer.
FALSE = 0
TRUE = !FALSE

But as it turns out, how you actually implement that can vary.

Gerald
There are 10 kinds of people in the world.
Those that understand Binary, and those that do not.
(oldie but goodie, and appropriate here)

"One Handed Man ( OHM - Terry Burns )" <news.microsoft .com> wrote in message news:OX******** ******@TK2MSFTN GP12.phx.gbl...

All of this is a bit superfluous really. I have discovered that the
compiler stores a +1 for True on the stack for a boolean type 'True' and 0 for a Boolean Type 'False'
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

As a side note, this is what makes the topic of -0 interesting.
If you do some research, you will see that when using two's complement,

you get

a couple of interesting exceptions to the rule that would seemingly

break things. But when they are resolved, they actually end up being what you wanted

in the first place.
-0 and +128 would be of significant note.
This is why a signed byte ranges from -128 to +127.
And not +- 127 or +- 128.

Gerald

"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:eq******** ******@TK2MSFTN GP10.phx.gbl...
> Ruffin,
>
> Middle Endian is when you fiddle with the byte ordering in the Word.
> 1-2-3-4 Big Endian
> 4-3-2-1 Little Endian
> 3-4-1-2 / 2-1-3-4 Middle Endian
>
> Take a look at:
> http://en.wikipedia.org/wiki/Endianness
>
> This works best on 16Bit computers living in the 32Bit world.
> In fact, some IO in Windows still works this way.
>
> Your confusion on the representation of Bits and why -1=11111111 and

not > 10000001 is because you are thinking as a human :)
> Binary math is simplified if you use "Two's Complement" representation of the

> binary for negative numbers.
> That is how computers like to do it.
> This would make the representation backwards from what you would

think. > Basically, take a positive representation, flip the bits, then add 1. > Take the value +1 = 0000001
> Flip the bits to make negative = 1111110
> Add 1 = 11111111
>
> So 11111111 = -1 in a Signed Byte
> In an Unsigned Byte, it would be 255
>
> Hope this helps to clear things up a little.
>
> Gerald
>
>
> "Ruffin Bailey" <ka****@mailina tor.com> wrote in message
> news:fd******** *************** ***@posting.goo gle.com...
> > "Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
> news:<#T******* *******@TK2MSFT NGP12.phx.gbl>. ..
> > > Additionally, by storing the Boolean value as all 1's or all 0's, you get

an
> > > additional performance gain when dealing with IO, as you can

ignore the

Byte
> > > Ordering (Little/Middle/Big Endean). 1111 = 1111 forward or

backward.

> >
> > What the heck is middle endian? ;^) The other two, being a Mac

user > > when I'm not at work, have pretty clear meanings.
> >
> > But this makes some sense for why things are -1 and not 1 or (as you > > point out below) -0. False is "everything off" and True is "every
> > switch on". And 11111111 = -1 -- but it's not -1 in signed Integers, > > which is confusing. That'd be 10000001, right?
> >
> > > IF you did have a 1 Bit signed integer type, if the value was not 0, it

> would
> > > be -1 (or -0, but that's a discussion for another day)
> >
> > Actually that makes sense and we can dispense with the new

discussion! > > ;^) That's part of my original wondering about why it works as it
> > does. 10000000 in a signed byte would be "negative 0000000". I've > > done just enough assembly
> > (http://mywebpages.comcast.net/rufbo1/mactari/mact.html) to have a
> > decent handle on how the bits work. It would have made sense to me to > > have "official True" be 10000000 (a quick rol to check) or 00000001 > > (1=1), but 10000001 (signed -1) didn't make much sense at all.
> >
> > Now, again, 11111111 is -1 in unsigned bytes, right? That makes some > > sense as True.
> >
> > Though admittedly I'm starting to wonder if I haven't got negative
> > signed byte expressions off in my head, as everyone seems to accept > > 11111111 (realizing I'm simplifying everything using one byte instead > > of 32 bit fun) as -1 *signed*. ???
> >
> > > A Boolean evaluation of an expression is actually a double negative. > > > If an expression does not evaluate to False(0), then it must be

True. So

all
> non
> > > zero values are True.
> >
> > That's been mentioned a few times, and immediately after posting it > > occurred to me to check and see what CBool(1) gave me (True). But why > > CInt(True) gave me -1 for "official True" was a mystery. I think the > > "all bits True in the byte" makes the most sense. Whether that's -1 > > in signed- or unsigned-land, I'll straighten out in my head later!
> >
> > Thanks everyone for the posts. Feel free to lambast my relatively
> > weak grasping of the situation! If I didn't have so many bad habits > > already, the "Turn on Option Strict" post my be the best suggestion of > > them all.
> >
> > Ruffin Bailey
>
>

[One Handed Man \( OHM - Terry Burns \)]

Like you, my 'C' days are well behind me ( probably for quite a few years ),
but I did used to have fun with it. My first program was to write a Star
Trek simulation ( text based ).

Ahh where did all those years go. ?

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
"Greg Young" <gr********@pla netbeach.com> wrote in message
news:e1******** *****@tk2msftng p13.phx.gbl...

I just miss using while(3) in C :(
"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

Agreed. I haven't investigated the actual implementation in dotNet or the

other

various languages.
This has become more about the mechanics of it all as opposed to the
implementation.
Although if one was to ask me to guess what the implementation would

have been,

my guess would not have been +1.
So I do find the actual implementation to be interesting.

In the end, I think Greg deserves the vote for the "best" answer.
FALSE = 0
TRUE = !FALSE

But as it turns out, how you actually implement that can vary.

Gerald
There are 10 kinds of people in the world.
Those that understand Binary, and those that do not.
(oldie but goodie, and appropriate here)

"One Handed Man ( OHM - Terry Burns )" <news.microsoft .com> wrote in message

news:OX******** ******@TK2MSFTN GP12.phx.gbl...

All of this is a bit superfluous really. I have discovered that the
compiler stores a +1 for True on the stack for a boolean type 'True'

and 0 for a Boolean Type 'False'
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
> As a side note, this is what makes the topic of -0 interesting.
> If you do some research, you will see that when using two's complement, you get
> a couple of interesting exceptions to the rule that would seemingly break > things. But when they are resolved, they actually end up being what you wanted
> in the first place.
> -0 and +128 would be of significant note.
> This is why a signed byte ranges from -128 to +127.
> And not +- 127 or +- 128.
>
> Gerald
>
> "Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
> news:eq******** ******@TK2MSFTN GP10.phx.gbl...
> > Ruffin,
> >
> > Middle Endian is when you fiddle with the byte ordering in the Word. > > 1-2-3-4 Big Endian
> > 4-3-2-1 Little Endian
> > 3-4-1-2 / 2-1-3-4 Middle Endian
> >
> > Take a look at:
> > http://en.wikipedia.org/wiki/Endianness
> >
> > This works best on 16Bit computers living in the 32Bit world.
> > In fact, some IO in Windows still works this way.
> >
> > Your confusion on the representation of Bits and why -1=11111111 and not

> > 10000001 is because you are thinking as a human :)
> > Binary math is simplified if you use "Two's Complement" representation of the
> > binary for negative numbers.
> > That is how computers like to do it.
> > This would make the representation backwards from what you would think. > > Basically, take a positive representation, flip the bits, then add 1. > > Take the value +1 = 0000001
> > Flip the bits to make negative = 1111110
> > Add 1 = 11111111
> >
> > So 11111111 = -1 in a Signed Byte
> > In an Unsigned Byte, it would be 255
> >
> > Hope this helps to clear things up a little.
> >
> > Gerald
> >
> >
> > "Ruffin Bailey" <ka****@mailina tor.com> wrote in message
> > news:fd******** *************** ***@posting.goo gle.com...
> > > "Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
> > news:<#T******* *******@TK2MSFT NGP12.phx.gbl>. ..
> > > > Additionally, by storing the Boolean value as all 1's or all 0's, you get
> an
> > > > additional performance gain when dealing with IO, as you can ignore the
> Byte
> > > > Ordering (Little/Middle/Big Endean). 1111 = 1111 forward or
backward.
> > >
> > > What the heck is middle endian? ;^) The other two, being a Mac user > > > when I'm not at work, have pretty clear meanings.
> > >
> > > But this makes some sense for why things are -1 and not 1 or (as you > > > point out below) -0. False is "everything off" and True is

"every > > > switch on". And 11111111 = -1 -- but it's not -1 in signed

Integers, > > > which is confusing. That'd be 10000001, right?
> > >
> > > > IF you did have a 1 Bit signed integer type, if the value was not 0, it
> > would
> > > > be -1 (or -0, but that's a discussion for another day)
> > >
> > > Actually that makes sense and we can dispense with the new discussion! > > > ;^) That's part of my original wondering about why it works as it > > > does. 10000000 in a signed byte would be "negative 0000000". I've > > > done just enough assembly
> > > (http://mywebpages.comcast.net/rufbo1/mactari/mact.html) to have a > > > decent handle on how the bits work. It would have made sense to me to > > > have "official True" be 10000000 (a quick rol to check) or 00000001 > > > (1=1), but 10000001 (signed -1) didn't make much sense at all.
> > >
> > > Now, again, 11111111 is -1 in unsigned bytes, right? That makes some > > > sense as True.
> > >
> > > Though admittedly I'm starting to wonder if I haven't got negative > > > signed byte expressions off in my head, as everyone seems to accept > > > 11111111 (realizing I'm simplifying everything using one byte instead > > > of 32 bit fun) as -1 *signed*. ???
> > >
> > > > A Boolean evaluation of an expression is actually a double negative. > > > > If an expression does not evaluate to False(0), then it must be True. So
> all
> > non
> > > > zero values are True.
> > >
> > > That's been mentioned a few times, and immediately after posting it > > > occurred to me to check and see what CBool(1) gave me (True). But why

> > > CInt(True) gave me -1 for "official True" was a mystery. I

think

the > > > "all bits True in the byte" makes the most sense. Whether that's -1 > > > in signed- or unsigned-land, I'll straighten out in my head

later! > > >
> > > Thanks everyone for the posts. Feel free to lambast my relatively > > > weak grasping of the situation! If I didn't have so many bad

habits > > > already, the "Turn on Option Strict" post my be the best suggestion of > > > them all.
> > >
> > > Ruffin Bailey
> >
> >
>
>

[One Handed Man \( OHM - Terry Burns \)]

Hey did u ever write assember for the BBC home computer ? Remember the 6502
processor with three registers, one accumulator and two addressing
registers. ?

I was only about 17 at the time, but it was big time fun. Those were the
days, no IDE, just peices of paper to do your design and fine mind !

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

Agreed. I haven't investigated the actual implementation in dotNet or the other various languages.
This has become more about the mechanics of it all as opposed to the
implementation.
Although if one was to ask me to guess what the implementation would have been, my guess would not have been +1.
So I do find the actual implementation to be interesting.

In the end, I think Greg deserves the vote for the "best" answer.
FALSE = 0
TRUE = !FALSE

But as it turns out, how you actually implement that can vary.

Gerald
There are 10 kinds of people in the world.
Those that understand Binary, and those that do not.
(oldie but goodie, and appropriate here)

"One Handed Man ( OHM - Terry Burns )" <news.microsoft .com> wrote in message news:OX******** ******@TK2MSFTN GP12.phx.gbl...

All of this is a bit superfluous really. I have discovered that the
compiler stores a +1 for True on the stack for a boolean type 'True' and 0 for a Boolean Type 'False'
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

As a side note, this is what makes the topic of -0 interesting.
If you do some research, you will see that when using two's complement,

you get

a couple of interesting exceptions to the rule that would seemingly

break things. But when they are resolved, they actually end up being what you wanted

in the first place.
-0 and +128 would be of significant note.
This is why a signed byte ranges from -128 to +127.
And not +- 127 or +- 128.

Gerald

"Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
news:eq******** ******@TK2MSFTN GP10.phx.gbl...
> Ruffin,
>
> Middle Endian is when you fiddle with the byte ordering in the Word.
> 1-2-3-4 Big Endian
> 4-3-2-1 Little Endian
> 3-4-1-2 / 2-1-3-4 Middle Endian
>
> Take a look at:
> http://en.wikipedia.org/wiki/Endianness
>
> This works best on 16Bit computers living in the 32Bit world.
> In fact, some IO in Windows still works this way.
>
> Your confusion on the representation of Bits and why -1=11111111 and

not > 10000001 is because you are thinking as a human :)
> Binary math is simplified if you use "Two's Complement" representation of the

> binary for negative numbers.
> That is how computers like to do it.
> This would make the representation backwards from what you would

think. > Basically, take a positive representation, flip the bits, then add 1. > Take the value +1 = 0000001
> Flip the bits to make negative = 1111110
> Add 1 = 11111111
>
> So 11111111 = -1 in a Signed Byte
> In an Unsigned Byte, it would be 255
>
> Hope this helps to clear things up a little.
>
> Gerald
>
>
> "Ruffin Bailey" <ka****@mailina tor.com> wrote in message
> news:fd******** *************** ***@posting.goo gle.com...
> > "Cablewizar d" <Ca*********@Ya hoo.com> wrote in message
> news:<#T******* *******@TK2MSFT NGP12.phx.gbl>. ..
> > > Additionally, by storing the Boolean value as all 1's or all 0's, you get

an
> > > additional performance gain when dealing with IO, as you can

ignore the

Byte
> > > Ordering (Little/Middle/Big Endean). 1111 = 1111 forward or

backward.

> >
> > What the heck is middle endian? ;^) The other two, being a Mac

user > > when I'm not at work, have pretty clear meanings.
> >
> > But this makes some sense for why things are -1 and not 1 or (as you > > point out below) -0. False is "everything off" and True is "every
> > switch on". And 11111111 = -1 -- but it's not -1 in signed Integers, > > which is confusing. That'd be 10000001, right?
> >
> > > IF you did have a 1 Bit signed integer type, if the value was not 0, it

> would
> > > be -1 (or -0, but that's a discussion for another day)
> >
> > Actually that makes sense and we can dispense with the new

discussion! > > ;^) That's part of my original wondering about why it works as it
> > does. 10000000 in a signed byte would be "negative 0000000". I've > > done just enough assembly
> > (http://mywebpages.comcast.net/rufbo1/mactari/mact.html) to have a
> > decent handle on how the bits work. It would have made sense to me to > > have "official True" be 10000000 (a quick rol to check) or 00000001 > > (1=1), but 10000001 (signed -1) didn't make much sense at all.
> >
> > Now, again, 11111111 is -1 in unsigned bytes, right? That makes some > > sense as True.
> >
> > Though admittedly I'm starting to wonder if I haven't got negative
> > signed byte expressions off in my head, as everyone seems to accept > > 11111111 (realizing I'm simplifying everything using one byte instead > > of 32 bit fun) as -1 *signed*. ???
> >
> > > A Boolean evaluation of an expression is actually a double negative. > > > If an expression does not evaluate to False(0), then it must be

True. So

all
> non
> > > zero values are True.
> >
> > That's been mentioned a few times, and immediately after posting it > > occurred to me to check and see what CBool(1) gave me (True). But why > > CInt(True) gave me -1 for "official True" was a mystery. I think the > > "all bits True in the byte" makes the most sense. Whether that's -1 > > in signed- or unsigned-land, I'll straighten out in my head later!
> >
> > Thanks everyone for the posts. Feel free to lambast my relatively
> > weak grasping of the situation! If I didn't have so many bad habits > > already, the "Turn on Option Strict" post my be the best suggestion of > > them all.
> >
> > Ruffin Bailey
>
>