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

  • Thread starter Thread starter Ruffin Bailey
  • Start date Start date
No, it is stored as a +1 one the stack.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
 
Cablewizard said:
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.
Click to expand...

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)
Click to expand...

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.
Click to expand...

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 said:
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.
Click to expand...

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)
Click to expand...

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.
Click to expand...

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,

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
 
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
 
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'
 
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)
 
I just miss using while(3) in C :(


Cablewizard said:
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
Click to expand...
 
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. ?
 
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 !
 
Actually, I have been rejecting another thought on this ( or rather
rejecting bringing it up ), but in JavaScript, when you look for an index of
something, it will either return False ( -1) or the index of the string. Now
once upon a time, ( and I might be wrong ), I thought that VB used to have
'1' based strings so to return '0' ( False ) meant you could not find the
occurance, this makes perfect sense to me if your strings are '1' based,
just as it does to return (-1) if your strings are '0' based.

Perhaps this is what made the difference ?
 
Cablewizard said:
In the end, I think Greg deserves the vote for the "best" answer.
FALSE = 0
TRUE = !FALSE
Click to expand...

Well, the obvious interesting question comes from why CBool(True)
gives -1. If Option Strict is Off, TRUE = !0 works, but the
curiousity is why "official True" is -1, not 1. Practically speaking
there's no reason to bother, I suppose, but my neurosis makes things
like this bother me. ;^)

Tried a few bits of C# to see if there's an equivalent (fraid I
haven't had much programming time in C#, though a good deal in Java),
and it seems to essentially "have Option Strict On", like it or not:
Console.WriteLine((int)true);
Console.WriteLine((Boolean)-1);
Console.WriteLine((Boolean)1);
Console.WriteLine((Boolean)0);

Each line reported an invalid cast. So that's not much help. Neither
was BooleanConverter, which just converted Booleans to strings and not
from ints to booleans or booleans to ints.

It's interesting that the compiler uses 1; might be interesting to
decompile some VB6 (or, better perhaps, VB1) code to see what it did
and see if there's a technical reason behind the -1.
So 11111111 = -1 in a Signed Byte
In an Unsigned Byte, it would be 255
Click to expand...

Except when you take "unsigned 0" and subtract one -- which will still
give you 11111111 (right? In the only hardware I know reasonably
well, you'll have a flag set that you've gone negative with the
substraction, I believe, but that's about it; the byte still holds
11111111). That's why I was thinking -1 = 11111111 in unsigned bytes
(so perhaps the right result from faulty reasoning).

I had the idea that signed bytes used the 7 bit (76543210) to store
the sign, apparently correctly, but sure did bork the storage of the
rest of the byte. Oh well, time to finally learn two's complement.
(Decent explanation: http://www.duke.edu/~twf/cps104/twoscomp.html)

Thanks for the help,

Ruffin Bailey

PS -- Talk about rethreading your head. Middle endianness is a mess!
 
LOL! Been there.
I moved a couple years ago, and just recently got around to sorting some of the
boxes.
In one box I had a handful of the 6502's still in original package.
Along with a whole mess of other things that might be fit for a history museum.

Gerald
 
as expected ...

using System;

namespace ConsoleApplication1
{
/// <summary>
/// Summary description for Class1.
/// </summary>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
Console.WriteLine(Convert.ToInt32(true));
Console.WriteLine(Convert.ToBoolean(-1));
Console.WriteLine(Convert.ToBoolean(1));
Console.WriteLine(Convert.ToBoolean(-325));
Console.WriteLine(Convert.ToBoolean(27));
Console.WriteLine(Convert.ToBoolean(0));
}
}
}


1
True
True
True
True
False
 
Back
Top