 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / General / July 2004Why is "False" = "-1"?
Why did VB define "False" as "-1" (when it gets converted to other data types) rather than "1"? How is boolean data stored internally? Just curious.  SignatureRunning MS VB 6.0 Pro (SP5) on Win2K-SR2 For email, use Usenet-20031220 at spamex.com > Why did VB define "False" as "-1" (when it gets converted to other > data types) rather than "1"? I think you mean "True, not "False". False <==> 0 But the answer is "by definition" in BASIC. The why is that "-1" is the logical complement of True (all bits on) for the specific length, integer or long. Some languages define True as +1 (only the one bit set) and others treat any non-zero value as True. The {0,-1) convention is probably most widespread as it is, as noted above the result of logical complement on the native processor data type. > How is boolean data stored internally? As either Integer or Long > Just curious. ...minds want to know... :) ... > > How is boolean data stored internally? > > As either Integer or Long Actually, I'm not absolutely positive about the length in VB (docs don't say) but I'm presuming it to be still be Integer although it could be any of the native integer types... > ... > > > How is boolean data stored internally? [quoted text clipped - 4 lines] > say) but I'm presuming it to be still be Integer although it could be > any of the native integer types... Dim x as Boolean Debug.Print LenB(x) Displays "2". Gale. > > ... > > > > How is boolean data stored internally? [quoted text clipped - 9 lines] > > Displays "2". Doh! :) > ... > > > How is boolean data stored internally? [quoted text clipped - 4 lines] > say) but I'm presuming it to be still be Integer although it could be > any of the native integer types... Check the Data Type Summary page of MSDN Library. A Boolean is not really an Integer or a Long, but it's 2 bytes (which is the same as an Integer). http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbenlr98/html/v agrpdatatype.asp Mike >> Why did VB define "False" as "-1" (when it gets converted to other >> data types) rather than "1"? > >I think you mean "True, not "False". False <==> 0 Yes, typo >But the answer is "by definition" in BASIC. The why is that "-1" is the >logical complement of True (all bits on) for the specific length, >integer or long. Unless the specified length is 1 bit. Even then, I suppose, "1" = "-1", if you are interpreting it as a signed number, but this is unintuitive to me. Boolean data is neither numeric nor signed. >Some languages define True as +1 (only the one bit set) and others treat >any non-zero value as True. The {0,-1) convention is probably most [quoted text clipped - 4 lines] > >As either Integer or Long What do you mean "either". Isn't it one or the other? If I declare a variable as Boolean Dim OnOff as Boolean it is stored some way -- not either one way or another, no? SignatureRunning MS VB 6.0 Pro (SP5) on Win2K-SR2 For email, use Usenet-20031220 at spamex.com ... > >But the answer is "by definition" in BASIC. The why is that "-1" is the > >logical complement of True (all bits on) for the specific length, [quoted text clipped - 3 lines] > "-1", if you are interpreting it as a signed number, but this is > unintuitive to me. Boolean data is neither numeric nor signed. True conceptually, but VB doesn't have an unsigned integer, therefore it will display it is a signed integer if asked for a non-Boolean representation of the internal representation. If you don't want the sign, use hex representation. Fundamentally it goes back being a language implementation definition and that choice is based on the fact that the logical complement operation is a machine instruction as well as it making sense for logical operations to either clear or set all bits in the word. ... > What do you mean "either". Isn't it one or the other? > If I declare a variable as Boolean > > Dim OnOff as Boolean > > it is stored some way -- not either one way or another, no? Yes, I meant I didn't recall offhand for sure which in VB--as I later posted and the Gale demonstrated it is as I surmised, 16 bit intger internally... >... >> >But the answer is "by definition" in BASIC. The why is that "-1" is the [quoted text clipped - 6 lines] > >True conceptually, but VB doesn't have an unsigned integer, Not to nitpick, but I believe type "Byte" is an unsigned integer (0-255). In any case, the hardware almost certainly has unsigned integer ops. SignatureRunning MS VB 6.0 Pro (SP5) on Win2K-SR2 For email, use Usenet-20031220 at spamex.com ... > >True conceptually, but VB doesn't have an unsigned integer, > > Not to nitpick, but I believe type "Byte" is an unsigned integer > (0-255). Yes, I was incomplete... :) > In any case, the hardware almost certainly has unsigned integer ops. True :) But doesn't matter if the language doesn't make use of them (except as you note in the case of Byte) and I was speaking only of the VB language implementation in that instance. Even for operations that may be carried out unsigned internally to VB, the i/o rtl will coerce the sign unless you do something to mask it. <snipped> > Unless the specified length is 1 bit. Even then, I suppose, "1" = > "-1", if you are interpreting it as a signed number, but this is > unintuitive to me. Boolean data is neither numeric nor signed. In the abstract you are right. Unfortunately in the real world (1's and 0's, machine words and bytes) a trade-off between convenience, speed, predictability, and validity is required. Some sort of convention has to be adopted using the tools at hand. Using a single bit would be ideal for the data type itself, but imagine the special handling that would be involved in managing a 'single bit' data type. After the bit-wise comparison was done, the result would have to converted to a 'single bit' data type. You would run into the same conversioning when comparing a Boolean value to an expression. Boolean abstract data types are actually a newcomer to scene in programming languages. All languages have had their little past 'boolean' conventions which always came with a "gotcha" somewhere in the mix. > >Some languages define True as +1 (only the one bit set) and others treat > >any non-zero value as True. The {0,-1) convention is probably most [quoted text clipped - 6 lines] > > What do you mean "either". Isn't it one or the other? Part of the problem when attempting to determine "internal" values while in VB is VB's 'helpful' data type coercion. A data type can often been printed or "displayed" as whatever you want it to be. So caution is always advisable. It does appear most often in asm as a 16bit Word/ VBInteger. -ralph > >Some languages define True as +1 (only the one bit set) and others treat > >any non-zero value as True. The {0,-1) convention is probably most > >widespread as it is, as noted above the result of logical complement on > >the native processor data type. Most languages define True and False as follows (or adhere to this principle anyway): FALSE = 0 TRUE = NOT FALSE IOW, FALSE is universally defined as 0 and TRUE is any non-zero, numeric value. Most languages, however, give an intrinsic value to 'true'. In C++, it's 1. In VB, it's -1 (the history behind this I don't know). (From here on, I'll use "TRUE" for C++ and "True" for VB). -----BEGIN SIDEBAR Originally, in VB.NET, True had an intrinsic value of 1 (so that it would be more in line with C++ and most other languages), but MS later decided against this due to many complaints from the VB community (or so I've heard this was the reason for the change). I'm pretty sure it was in the 2nd beta of VB.NET that MS went back to conform to the "conventional VB way" (meaning they made True = -1 again). At least this means that MS listened, although I don't personally agree with the decision. If VB programmers had been using True and False properly, this would have never been an issue. But too many programmers wrote code like 'If A = -1 Then' as opposed to using the intrinsic constant True. This is probably due (IMO) to True and False originally not being intrinsic constants in VB (you had to declare them yourself). IIRC, VB3 was the first version to have the intrinsic constants True and False (I verified that VB3 has these; I have VB2 still, but it's not installed to verify True and False constants in it). However, instead of declaring 'true' and 'false' constants, programmers just used -1 and 0 everywhere, and then never bothered to changed their ways (so even as late as VB6, many programmers were still using -1 and 0 instead of True and False). -----END SIDEBAR Anyway, VB does support the 'FALSE = 0' and 'TRUE = NOT FALSE' definitions. That's why you can write code like this: Dim A As Integer A = 1 'or assign any non-zero value If A Then MsgBox "A is ""TRUE""" Else MsgBox "A is ""FALSE""" End If It's always been my understanding that 'If A Then' executes slightly faster than 'If A = 1 Then' (or 'If A = -1 Then' or 'If A = True Then'). However, many programmers consider 'If A Then' not to be as understandable (usually because they're not aware of the TRUE = NOT FALSE definition). For other programmers, such syntax is 2nd nature. True having a value of -1 in VB usually isn't problematic when dealing strictly with VB code. It's when you mix in what other languages expect, for example the Windows API, that problems generally arise. The API was written, and is documented, with C/C++ programmers in mind. The documentation frequently says to pass TRUE or FALSE for a parameter, and this can lead to problems if you pass VB's True constant. The majority of API functions adhere to the TRUE = NOT FALSE definition; so, if the API function expects either TRUE or FALSE and you pass any non-zero value, the API function will still work as expected. For all API functions, if you pass VB's True constant (because, afterall, the documentation says to pass TRUE), the API function receives the value -1. However, you *will* find some API functions that don't adhere to the TRUE = NOT FALSE definition (and this is NOT documented). IOW, the function is hard-coded to expect 0 for FALSE and 1 for TRUE, and it's anybody's guess as to how the function will treat any other value (other than whomever wrote the function, and probably others at MS). For such functions, if you pass anything other than 0 or 1 (positive 1 because that's the intrinsic value of TRUE in C/C++), the API function will not work as expected. There's a very simple way to sum all this up: In VB, NEVER pass True to an API function. Always pass 1 (or better, 1& to avoid VB having to coerce it to a Long) if you need to pass a TRUE value. OK....so much for my little tutorial of the day. I hope it helps somewhat. Mike MikeD, > IOW, FALSE is universally defined as 0 and TRUE is any non-zero, numeric > value. Most languages, however, give an intrinsic value to 'true'. In C++, > it's 1. In VB, it's -1 (the history behind this I don't know). (From here > on, I'll use "TRUE" for C++ and "True" for VB). Actually, C++ only recently got a true boolean data type (bool). TRUE is a macro definition that is defined in the Windows header files and is not part of the language proper. However, Microsoft recently added the bool data type, which is one byte and does contain a value of 0 or 1 (the constants are case sensitive "true" and "false"). > It's always been my understanding that 'If A Then' executes slightly faster > than 'If A = 1 Then' (or 'If A = -1 Then' or 'If A = True Then'). This is not true. In both cases, A must be compared to zero or some other value. The resulting code is the same. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > > It's always been my understanding that 'If A Then' executes slightly > faster > > than 'If A = 1 Then' (or 'If A = -1 Then' or 'If A = True Then'). > > This is not true. In both cases, A must be compared to zero or some other > value. The resulting code is the same. I don't quite understand your comment, at least as it relates to the point I was attempting to make. You seem to be saying that syntax such as 'If A Then' does not work. It most certainly does, but one must understand how it is different than a full comparison (such as 'If A = 1 Then'). By no means do these 2 syntaxes evaluate identically. I hope I did not imply that they did (and if I did, I apologize for any confusion it might have caused). Let's assume A is assigned a value of 2 instead of 1. 'If A Then' will still evaluate to True. 'If A = 1 Then', however, will evaluate to False. The first syntax is applicable *only* when you're concerned with knowing whether A is true or false. IOW, the full comparison equivalent to 'If A Then' would be 'If CBool(A) = True Then'. 'If A Then' is just a shortcut. If you need to determine whether A is assigned a specific value, then you're right in that you must actually compare A to a value. The point I was making was that 'If A Then' executes slightly faster than 'If CBool(A) = True Then'. I guess I should have made that clearer. I can understand how my original post was confusing in this regard. Sorry about that. Mike > > > It's always been my understanding that 'If A Then' executes slightly > > faster [quoted text clipped - 5 lines] > I don't quite understand your comment, at least as it relates to the point I > was attempting to make. No, he (we) understood exactly...the point is your contention is simply wrong... ...snip babbling... > The point I was making was that 'If A Then' executes slightly faster than > 'If CBool(A) = True Then'. I guess I should have made that clearer. I can > understand how my original post was confusing in this regard. Sorry about <IF> the above contention <were> to be true (I've not taken the time to actually look at the generated code), it would only be because of the (unnecessary) cast that is written into the latter that VB perhaps would not optimize out... You would perhaps find it instructive to look at some of the details Dan Barclay has in his article to which he posted a link... In a nutshell, writing "If A Then" is <precisely> identical to writing "If A<>0 Then" and will generate the same code and therefore the same execution time. (Excepting perhaps for a <very> dumb compiler and I believe Dan's article shows that the VB compiler isn't that dumb--actually a couple of his examples show better code generation than I had suspected). This is conclusion can be generalized to cover any and all of the cases/pseudo-examples you've previously provided--they all boil down to either an eq or ne and there has to be something for the machine instruction to compare to--whether it's zero or nonzero makes no difference. > In a nutshell, writing "If A Then" is <precisely> identical to writing > "If A<>0 Then" and will generate the same code and therefore the same [quoted text clipped - 6 lines] > the machine instruction to compare to--whether it's zero or nonzero > makes no difference. OK. I can buy that. It was many years ago that I had heard and read (from many different sources) that 'If A Then" executed quicker. I can see how that may have been the case prior to VB having native code compilation, but with native code compilation, it is no longer true (because native code compilation does optimize the code just as you say). In all honesty, I never gave it a whole lot of thought. Mike ... > OK. I can buy that. It was many years ago that I had heard and read (from > many different sources) that 'If A Then" executed quicker. I can see how > that may have been the case prior to VB having native code compilation, but > with native code compilation, it is no longer true (because native code > compilation does optimize the code just as you say). In all honesty, I never > gave it a whole lot of thought. Ah...now if you'd restricted the claim to interpreted BASIC, that <would> have been a different kettle of fish... "Duane Bozarth" <dp_bozarth@swko.dot.net> wrote > In a nutshell, writing "If A Then" is <precisely> identical to writing > "If A<>0 Then" and will generate the same code and therefore the same [quoted text clipped - 6 lines] > the machine instruction to compare to--whether it's zero or nonzero > makes no difference. Most of that is correct, a look at the M/L would have shown that they do not really do a compare operation for the short version: If a = -1 Then a = 1 00000018 cmp esi,0FFFFFFFFh 0000001b jne 00000022 0000001d mov esi,1 If CBool(a) Then a = 2 00000022 test esi,esi 00000024 je 0000002B 00000026 mov esi,2 CMP is a subtraction operation where the temporary result sets the status flags TEST is a bitwise AND operation where the temporary result sets the status flags CMP and TEST both make use of a temporary value which is thrown out after the operation is complete. That is different from SUB and AND that both store the result back into the location of one of the operands. CMP and TEST are going to be a cycle or two quicker than SUB and AND because they do not need to store the result of the operation. As can be seen, for all practical purposes, there is virtually no difference between the two If methods used. LFS Larry, > > In a nutshell, writing "If A Then" is <precisely> identical to writing > > "If A<>0 Then" and will generate the same code and therefore the same [quoted text clipped - 18 lines] > 00000024 je 0000002B > 00000026 mov esi,2 I think you misread what Duane wrote. He was specifically comparing 'If A Then' to 'If A <> 0 Then' (as he stated). You are comparing tests against non-zero values with tests of a CBool conversion. I'm not sure what happened there. Duane was correct. Many compilers will generate code that uses TEST to compare against zero. This is because early processors cold perform TEST reg,reg slightly faster than CMP reg,immed (even though the 486 and higher perform both operations in a single clock cycle). I can't guarantee, but would expect both cases Duane was comparing to generate instructions using TEST. > CMP and TEST both make use of a temporary value which is thrown out after > the operation is complete. That is different from SUB and AND that both store > the result back into the location of one of the operands. CMP and TEST are > going to be a cycle or two quicker than SUB and AND because they do not > need to store the result of the operation. While it is true that CMP and TEST do not store the result, most modern processors perform these operations every bit as fast as SUB and AND. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm "Jonathan Wood" <jwood@softcircuits.com> wrote > I think you misread what Duane wrote. He was specifically comparing 'If A > Then' to 'If A <> 0 Then' (as he stated). You are comparing tests against > non-zero values with tests of a CBool conversion. I'm not sure what happened > there. Oops.. <g> FWIW: (Since I still have it set up...) >..> The point I was making was that 'If A Then' executes slightly faster than >..> 'If CBool(A) = True Then'. I guess I should have made that clearer. I can >..> understand how my original post was confusing in this regard. If a Then a = 1 00000018 test esi,esi 0000001a je 00000021 0000001c mov esi,1 If CBool(a) = True Then a = 2 00000021 test esi,esi 00000023 je 0000002A 00000025 mov esi,2 >..> In a nutshell, writing "If A Then" is <precisely> identical to writing >..> "If A<>0 Then" and will generate the same code and therefore the same >..> execution time. If a <> 0 Then a = 2 00000021 test esi,esi 00000023 je 0000002A 00000025 mov esi,2 > While it is true that CMP and TEST do not store the result, most modern > processors perform these operations every bit as fast as SUB and AND. I can believe that, the documentation I have on the X86 instruction set is is from quite a few years back... (1997) LFS Larry, > If a Then a = 1 > 00000018 test esi,esi [quoted text clipped - 4 lines] > 00000023 je 0000002A > 00000025 mov esi,2 Yup, pretty much as expected. I would expect the second code to be the same if 'If a <> 0 Then' was used. > I can believe that, the documentation I have on the X86 instruction set is > is from quite a few years back... (1997) Heh, I have one that covers up to the 486. Definitely time for an updated reference. :-) SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > While it is true that CMP and TEST do not store the result, most > modern processors perform these operations every bit as fast as SUB > and AND. Hi Jonathan - Those individual operations each take one cycle, but TEST pipelines better, so it's preferred over CMP and SUB, at least if your code is written for use on any processor. Compilers are probably the only place it makes a difference, since hand-tuning to avoid pipe stalls is something very few people do. Of course, you and I do, but... :-) SignatureJim Hi Jim, > Those individual operations each take one cycle, but TEST pipelines > better, so it's preferred over CMP and SUB, at least if your code is > written for use on any processor. That would explain why I always see TEST favored over CMP. > Compilers are probably the only place it makes a difference, since > hand-tuning to avoid pipe stalls is something very few people do. Of > course, you and I do, but... :-) Heh, well, I know you do but I'm actually not familiar with how to avoid pipe stalls. My assembler reference discusses clock cycles and includes information about how various addressing methods and modes also affect the clock cycles required. But it has nothing about getting data to the processor. Where do you get information like this? Thanks. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > Hi Jim, > > My assembler reference discusses clock cycles and includes > information about how various addressing methods and modes also > affect the clock cycles required. But it has nothing about getting > data to the processor. Where do you get information like this? Intel publishes white papers that discuss instruction pairing and other such esoterica, and there are still some very active ASM groups in the comp.lang heirarchy and elsewhere. The best of these people genuinely know their stuff. It will soon, if it hasn't already, get to the point where humans aren't suitable for the task of optimizing at this level. It seems that with every product cycle the rules (even the rules of thumb) change and the complications pile up. And given that comilers have their own product cycle, it's a constant game of catch-up. SignatureJim Mack Hi Jim, Long time, no see<g> <snip> > Compilers are probably the only place it makes a difference, since > hand-tuning to avoid pipe stalls is something very few people do. Of > course, you and I do, but... :-) You're probably the only one on the planet <g>. MS would just tell me to get rid of my outdated computer and get a faster one! You still overworked these days, or looking for an interesting project? Later, Dan > Hi Jim, > [quoted text clipped - 10 lines] > You're probably the only one on the planet <g>. MS would just tell > me to get rid of my outdated computer and get a faster one! There is a substantial (but shrinking) hard core of ASM programmers who know this stuff inside out and can code rings around me and you. I know because I intermittently read the groups where they hang out. To these folks, instruction pairing and pipeline stalls are what sports stats are to the rest of the world. > You still overworked these days, or looking for an interesting > project? Yes to both :-) My peak season doesn't start for a couple of months... drop me an email. SignatureJim > > You're probably the only one on the planet <g>. MS would just tell > > me to get rid of my outdated computer and get a faster one! [quoted text clipped - 4 lines] > folks, instruction pairing and pipeline stalls are what sports stats are > to the rest of the world. I've long forgot how to do anything useful in asm <sigh>. I have considered taking it up again though. Gotta leave VB. IL isn't that hard, especially since they've got variables and such<g>. It sure doesn't feel much like asm (hmm... maybe 'cause it ain't!)<g>. > > You still overworked these days, or looking for an interesting > > project? > > Yes to both :-) My peak season doesn't start for a couple of months... > drop me an email. Done. Dan > > While it is true that CMP and TEST do not store the result, most > > modern processors perform these operations every bit as fast as SUB [quoted text clipped - 3 lines] > better, so it's preferred over CMP and SUB, at least if your code is > written for use on any processor. I find it a bit surprising that CMP and SUB can store a result back out to relative memory in the same cycle they are fetched, but I don't follow assembly that close anymore. About the time they added pipelining, prefetch, or look-ahead, I started thinking I don't really need to get this focused... ;-) But, I would be interested if you knew of a downloadable reference that covers such details in the current architectures. It can't hurt to get more up to date before I make another remark like the previous 'cycle or two quicker' example.... LFS >> > While it is true that CMP and TEST do not store the result, most >> > modern processors perform these operations every bit as fast as SUB [quoted text clipped - 14 lines] >get more up to date before I make another remark like the previous >'cycle or two quicker' example.... One of my 'bibles' is an ancient DOS Help System - the interface is lousy, but the info is good I have a copy here : www.jerryfrench.co.uk/helppc.zip (all lowercase) Jeez, Larry Serflaten Jim Mack Jonathan Wood Dan Barclay I think I logged into the wrong century by mistake! Andy, > Larry Serflaten > Jim Mack > Jonathan Wood > Dan Barclay > > I think I logged into the wrong century by mistake! Heh, there may not be as many people doing assembler these days, but as long as you are using a tool that runs on Intel processors, your work relies on the many people who worked out the machine instructions produced by the tools you use. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > Andy, > [quoted text clipped - 9 lines] > the many people who worked out the machine instructions produced by the > tools you use. What!!?!!! You mean they're not objects under there?? <gasp> Dan > Jeez, > [quoted text clipped - 4 lines] > > I think I logged into the wrong century by mistake! LOL! :-) Signature[Microsoft Basic: 1976-2001, RIP] There's a debug program like the MS-DOS debug program which is supposed to have support for the MMX instruction set... I was reading a newsgroup article in one of the assembly newsgroups about it supporting the SSE instruction set. I just downloaded it... http://members.tripod.com/~ladsoft/grdb.htm It runs very much like Microsoft's debug.exe. One of the first I noticed is the eax, ebx, etc when you type in the r command to display the registers. Source code for it is available at the site as well. Intel documents the Pentium III SSE instructions in: http://www.intel.com/design/pentiumii/manuals/24512701.pdf Another reference for is entitled "Pentium 4 Processor Optimization Reference Manual" available here: http://www.intel.com/design/pentium4/manuals/248966.htm and the PDF is here: http://www.cs.cornell.edu/courses/cs412/2001sp/resources/Pentium%20Processor%20O ptimization.pdf Not sure if that is what you are looking for but it is definitely some interesting stuff. SignatureJim Carlock http://www.votetoimpeach.org/ Post replies to the newsgroup. "Jim Mack" wrote: > > While it is true that CMP and TEST do not store the result, most > > modern processors perform these operations every bit as fast as SUB [quoted text clipped - 3 lines] > better, so it's preferred over CMP and SUB, at least if your code is > written for use on any processor. I find it a bit surprising that CMP and SUB can store a result back out to relative memory in the same cycle they are fetched, but I don't follow assembly that close anymore. About the time they added pipelining, prefetch, or look-ahead, I started thinking I don't really need to get this focused... ;-) But, I would be interested if you knew of a downloadable reference that covers such details in the current architectures. It can't hurt to get more up to date before I make another remark like the previous 'cycle or two quicker' example.... LFS MikeD, > Let's assume A is assigned a value of 2 instead of 1. 'If A Then' will > still evaluate to True. 'If A = 1 Then', however, will evaluate to False. [quoted text clipped - 3 lines] > If you need to determine whether A is assigned a specific value, then you're > right in that you must actually compare A to a value. The following two statements are equal: If A Then If A <> 0 Then In both cases, A must be compared to zero and a jump performed if they match. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > > >Some languages define True as +1 (only the one bit set) and others treat > > >any non-zero value as True. The {0,-1) convention is probably most [quoted text clipped - 11 lines] > it's 1. In VB, it's -1 (the history behind this I don't know). (From here > on, I'll use "TRUE" for C++ and "True" for VB). But the difference between VB (whose precedent was Princeton BASIC and the ANSI BASIC Standard) and C/C++is in the definition of "NOT"--iow, "not false" depends on the not operation defined in the language. In VB, Not is a bitwise complement which explains where the -1 comes from. In C, K&R didn't actually define True/False per se--instead it is described in conjunction with the "unary logical negation operator" ! as "1 if the value of its operand is 0, 0 if the value of its operand is non-zero" (I just went and looked it up in K&R '78 to refresh my memory as being correct). Thus, in C, the negation operator "~" is the equivalent of VB's "Not" and there is not VB operator equivalent to C's "!". This is the source of the confusion because in VB (Not 1) ==> True rather than False. If C code is properly formed, !(-1) or !1 will both yield 0, only if the C code is ill-formed and tests for equality to 1 does there arise a problem. Top Spin, For the reason True is -1 (and some other background) See: http://www.mvps.org/vb/tips/truth.htm Dan > >> Why did VB define "False" as "-1" (when it gets converted to other > >> data types) rather than "1"? [quoted text clipped - 27 lines] > > it is stored some way -- not either one way or another, no? > Why did VB define "False" as "-1" (when it gets converted to other > data types) rather than "1"? > > How is boolean data stored internally? > > Just curious. Actually "-1" is "True" not "False". Where or how did you determine that it was evaluated as "False"? [There are some situations when dealing with the API (or other 3rd party libraries) that "-1" will be interpreted as False, because the Win32 API is written in C. In C, zero is "False" and anything else is "True".] Take a look at the following.. http://www.mvps.org/vb/index2.html?tips/truth.htm hth -ralph > Why did VB define "False" as "-1" (when it gets converted to other > data types) rather than "1"? Think you made a mistake here...False = 0, True = -1 (but any value other than 0 will evaluate to True in a boolean expression). > How is boolean data stored internally? Boolean data is (or at least was) stored as an integer. All the bits off (0) is False, all the bits on (-1) is true. Austin SignatureYou programmed with 1s and 0s? We only had 0s! There are no X characters in my address >> Why did VB define "False" as "-1" (when it gets converted to other >> data types) rather than "1"? [quoted text clipped - 7 lines] > >Austin Hmmm... Well, it seems to me that it all depends on how the boolean express is being used.. For example try this one out for size: If 1 Then Print "True" Else Print "False" End If Have a good day... Don > > (but any value other > >than 0 will evaluate to True in a boolean expression). > Hmmm... Well, it seems to me that it all depends on how the boolean express is > being used.. [quoted text clipped - 4 lines] > Print "False" > End If Sometimes ya gotta read the fine print... Austin > > > (but any value other > > >than 0 will evaluate to True in a boolean expression). [quoted text clipped - 10 lines] > > Sometimes ya gotta read the fine print... Yes, you do. Logical expression evaluation is bitwise, but *tests* are value-wise. Zero is false, nonzero is true. More fine print at: http://www.mvps.org/vb/tips/truth.htm Dan >> Why did VB define "False" as "-1" (when it gets converted to other >> data types) rather than "1"? [quoted text clipped - 5 lines] >Boolean data is (or at least was) stored as an integer. All the bits off >(0) is False, all the bits on (-1) is true. Personally, I find it inconsistent (and illogical) to call all 1's (of whatever length) "-1" for a "logical" data type. The high-order bit being a "1" represents negative numbers only for signed numbers using twos complement form. Type "Byte", for example, an unsigned numeric data type, has a range of 0-255, not (-128)-127. Whereas type "Integer", a signed data type, has a range of (-32,768)-32,767. Anyway, that's the way it is. Just code around it. SignatureRunning MS VB 6.0 Pro (SP5) on Win2K-SR2 For email, use Usenet-20031220 at spamex.com ... > Personally, I find it inconsistent (and illogical) to call all 1's (of > whatever length) "-1" for a "logical" data type. The high-order bit > being a "1" represents negative numbers only for signed numbers using > twos complement form. Type "Byte", for example, an unsigned numeric > data type, has a range of 0-255, not (-128)-127. Whereas type > "Integer", a signed data type, has a range of (-32,768)-32,767. But if you print it as anything other than as its Boolean representation of "True" or "False", it <isn't> a "logical" data type any longer--you've coerced its internal representation to an integer and VB doesn't have an unsigned integer (again, not counting Byte, and Boolean is longer than Byte so coercion doesn't succeed anyway unless you mask, etc.)... > Anyway, that's the way it is. Just code around it. But you're the one who asked??? Or are you simply resigning yourself to the fact that VB doesn't have unsigned uInteger or uLong? (Of course, Fortran doesn't, either...) :( "AustinMN" <tacooperX@Xatt.net> wrote > > How is boolean data stored internally? > Boolean data is (or at least was) stored as an integer. All the bits off > (0) is False, all the bits on (-1) is true. Another way to look at it: All bits off = False Any bits on = True LFS Top Spin, > Why did VB define "False" as "-1" (when it gets converted to other > data types) rather than "1"? Actually, False is 0, and True is -1. The reason for this is that VB does not support logical operators, it supports bitwise operators. Consider the following: If 1 And 2 Then ... Even though 1 and 2 are non-zero, this expression would be considered false and the lines after Then would not execute. If you used a language such as C that supports logical operators, both 1 and 2 would be considered True. However, because VB does bitwise operations, the two values are ANDed together resulting in zero. To avoid this type of error (although not completely), VB uses -1 for True, which is &HFFFF, which has all the bits set. That way, when you And True with any non-zero value, you will always get true. > How is boolean data stored internally? As a 16-bit integer. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > Why did VB define "False" as "-1" (when it gets converted to other > data types) rather than "1"? > > How is boolean data stored internally? > > Just curious. This might help you... go to this page http://www.mvps.org/vb/ click on its "Tipsheets" link in the left hand frame and select "MS Basic Logical Expression Evaluation: The History of Truth" from the right hand frame. Rick - MVP >Why did VB define "False" as "-1" (when it gets converted to other >data types) rather than "1"? > >How is boolean data stored internally? > >Just curious. False = 0 True is ambivelent ... > False = 0 > True is ambivelent Yes and no... :) > ... > > False = 0 > > True is ambivelent > > Yes and no... :) And neither do I, too! <g> Gale. it isn't. False = 0 True = -1 because it is NOT 0 - here NOT is a logic function the logic function NOT inverts all the bits in the value and any non-zero result can be taken as true. But in the strictest sense, false=0000000000000000 which when inverted is 1111111111111111 which is -1 in binary math (2's compliment) a bit more on 2's compliment which is a way to represent +ve & -ve numbers in cpu registers mainly. 1's compliment is a simple invert... this results in the two bit patterns of 1s & 0s above, but consider that your PC expects the numbers to be in a range that supports +ve & -ve, it expects the number to be a 2's compliment representation. 2's compliment is "invert the bits and add one", so if we consider the value 1 in binary (16 bits) is 0000000000000001 inverted it gives (1's compliment) 1111111111111110 and add one gives (2's compliment) 1111111111111111 simple eh? :o/ this also explains why the number ranges of integers are alway bigger (by one) when negative, i.e. -32768 to +32767 > Why did VB define "False" as "-1" (when it gets converted to other > data types) rather than "1"? > > How is boolean data stored internally? > > Just curious. ... > false=0000000000000000 > > which when inverted is > > 1111111111111111 which is -1 in binary math (2's compliment) ... This is very complimentary, but the complement is what you're discussing... :) Uncle, > True = -1 because it is NOT 0 - here NOT is a logic function > [quoted text clipped - 6 lines] > > 1111111111111111 which is -1 in binary math (2's compliment) I don't know why people insist on saying this. Not is bitwise, not logical. If it were logical, then NOT 1 would result in False (0). SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm > Uncle, > [quoted text clipped - 11 lines] > I don't know why people insist on saying this. Not is bitwise, not logical. > If it were logical, then NOT 1 would result in False (0). before there were CPUs, there was logic. NOT 1 = 0, it doesn't matter how many bits. > > Uncle, > > [quoted text clipped - 16 lines] > before there were CPUs, there was logic. NOT 1 = 0, it doesn't matter how > many bits. LOL Then came... is it 'not' when the voltage goes up, or when it comes down? UncleWobbly, > > I don't know why people insist on saying this. Not is bitwise, not > logical. > > If it were logical, then NOT 1 would result in False (0). > > before there were CPUs, there was logic. NOT 1 = 0, it doesn't matter how > many bits. Exactly. When NOT 1 = &HFFFE, then you know you're talking about bitwise operators and not logical ones. SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm >> Uncle, >> [quoted text clipped - 16 lines] > before there were CPUs, there was logic. NOT 1 = 0, it doesn't > matter how many bits. Of course it matters. It would only not matter if you were running a single-bit CPU. And besides, it matters because we ARE talking about CPUs, and a particular language implementation. Your own example shows that you know this. Logical operators require that all inputs are booleans, and they generate boolean states as a result. If the inputs are not already boolean types, they're implicitly coerced, using the rule that 0 = false and anything else = true. But unlike C, classic VB has no logical operators, only bitwise operators and boolean data types. It does not coerce numerics to booleans when used as arguments to the bitwise operators, so that step is left to the programmer (CBool). You can safely use the bitwise operators as logical operators only if you insure that the inputs are booleans, or equivalent. The Not operator inverts, individually, each of the bits in its argument. Only when all the bits have the same value will Not perform a logical negation, as a side-effect of its real purpose. ============ As a side note for anyone reading this thread: we can (but shouldn't) rely on implicit conversion when assigning a value to a boolean -- for example: Dim Boole as Booean ..... Boole = 37 ' Does an implicit Boole = CBool(37) But there's at least one situation where after an assignment you can end up with an indeterminate value in a VB Boolean data type -- that is, where not all bits have the same state. Does anyone know what it is? (I'm not talking about CopyMem or LSet or other deliberate tricks.) 100 Nerd Points for the first answer. SignatureJim Jim, > As a side note for anyone reading this thread: we can (but shouldn't) > rely on implicit conversion when assigning a value to a boolean -- for [quoted text clipped - 3 lines] > ..... > Boole = 37 ' Does an implicit Boole = CBool(37) As a side note to your side note, MS C++ recently added the bool data type. The following code: int i = 37; bool b = i; Causes a compiler performance warning. While it looks like a simple assignment, the code it generates appears to do this: int i; bool b; if (i == 0) b = false; else b = true; SignatureJonathan Wood SoftCircuits http://www.softcircuits.com Available for consulting: http://www.softcircuits.com/jwood/resume.htm About the only thing I can think of right off the top of my head is that if an API call returns 0 for success, anything else as an error code... but then the type wouldn't be a Boolean type, but would be a Long or an Integer, so that would mean properly declaring the API call... I don't know if that is to what you're refering but I'll take the 100 Nerd Points anyways for being the first answer. SignatureJim Carlock http://www.votetoimpeach.org/ Post replies to the newsgroup. UncleWobbly wrote: > "Jonathan Wood" wrote: >> Uncle, [quoted text clipped - 17 lines] > before there were CPUs, there was logic. NOT 1 = 0, it doesn't > matter how many bits. Of course it matters. It would only not matter if you were running a single-bit CPU. And besides, it matters because we ARE talking about CPUs, and a particular language implementation. Your own example shows that you know this. Logical operators require that all inputs are booleans, and they generate boolean states as a result. If the inputs are not already boolean types, they're implicitly coerced, using the rule that 0 = false and anything else = true. But unlike C, classic VB has no logical operators, only bitwise operators and boolean data types. It does not coerce numerics to booleans when used as arguments to the bitwise operators, so that step is left to the programmer (CBool). You can safely use the bitwise operators as logical operators only if you insure that the inputs are booleans, or equivalent. The Not operator inverts, individually, each of the bits in its argument. Only when all the bits have the same value will Not perform a logical negation, as a side-effect of its real purpose. ============ As a side note for anyone reading this thread: we can (but shouldn't) rely on implicit conversion when assigning a value to a boolean -- for example: Dim Boole as Booean ..... Boole = 37 ' Does an implicit Boole = CBool(37) But there's at least one situation where after an assignment you can end up with an indeterminate value in a VB Boolean data type -- that is, where not all bits have the same state. Does anyone know what it is? (I'm not talking about CopyMem or LSet or other deliberate tricks.) 100 Nerd Points for the first answer. SignatureJim >> But there's at least one situation where after an assignment you can >> end up with an indeterminate value in a VB Boolean data type -- that >> is, where not all bits have the same state. Does anyone know what it >> is? (I'm not talking about CopyMem or LSet or other deliberate >> tricks.) 100 Nerd Points for the first answer. > About the only thing I can think of right off the top of my head > is that if an API call returns 0 for success, anything else as an [quoted text clipped - 7 lines] > -- > Jim Carlock Close enough, claim your points. The situation is when you declare an external function as having type Boolean which actually returns 0 or 1 (C-style). Lots of APIs say they return True or False but they shouldn't be Declared as Boolean for this reason. You can get into the trap: Declare Function SomeAPI(nuts) As Boolean 'returns a C-style bool Dim Boole as Boolean Boole = SomeAPI(asdadf) ' return value should be coerced to Boolean by assignment Debug.Print Boole ' prints "True" Debug.Print Not Boole ' also prints "True" The Declare causes the compiler to "trust" the API, so it just stuffs its return value into the variable without any check. SignatureJim Mack > >> But there's at least one situation where after an assignment you can > >> end up with an indeterminate value in a VB Boolean data type -- that [quoted text clipped - 35 lines] > The Declare causes the compiler to "trust" the API, so it just stuffs > its return value into the variable without any check. Boy, did I get off track - I spent a few fruitless attempts at seeing if it was possible to somehow assign a signed-zero, etc. <g> As a corollary to your explanation, it is not only just 'C' style API calls that can burn you. COM calls that return a HREF often contain an 'out' error parameter. VB strips the HREF (uses it for Err) and 'returns' the error parameter. C/C++ COM programmers can be just as lazy as what you pointed out above - frequently returning whatever non-zero value is available at the moment to indicate 'true'. -ralph There's a theory about signed-zero's... it has to do with the fact that as you approach zero from the positive side the number involved gets to be a smaller and smaller positive number, and as you approach it from the negative side, the number gets to be a smaller and smaller negative quantity. When using such small numbers in mathematics, to measure things that are directly proportional to approaching zero, quantitification starts approaching bigger and bigger numbers. 1 + 1 = 0 1/0 + 1/0 = infinity We are not really dividing by 0 there. We are dividing by n as n approaches 0. If you approach 0 from the positive side 1 / (n ->0), n starts getting smaller and smaller, and 1/n starts getting bigger and bigger. Therefore, 1+1 = infinity... but you can take it one step farther and approach 0 from the negative side and you get: 1/(-n->0) = -inifinity Now if you add the two equations together: -infinity + infinity you get 0. Therefore 1+1 = 0. :-) SignatureJim Carlock http://www.votetoimpeach.org/ Post replies to the newsgroup. "Jim Mack" wrote: > Jim Carlock wrote: > [quoted text clipped - 37 lines] > The Declare causes the compiler to "trust" the API, so it just stuffs > its return value into the variable without any check. Boy, did I get off track - I spent a few fruitless attempts at seeing if it was possible to somehow assign a signed-zero, etc. <g> As a corollary to your explanation, it is not only just 'C' style API calls that can burn you. COM calls that return a HREF often contain an 'out' error parameter. VB strips the HREF (uses it for Err) and 'returns' the error parameter. C/C++ COM programmers can be just as lazy as what you pointed out above - frequently returning whatever non-zero value is available at the moment to indicate 'true'. -ralph Booleans are stored as 2 bytes. False is defined as 0, while True = Not False. Showing our work: False: 00000000 00000000 True: 11111111 11111111 (not each bit) Which in an Integer is "-1". Having babbled on about this, one issue I've made approximately 2ce a year is that Not False <> True. For example (overly simplified): Dim x as integer = 6 '6 <> 0, therefore 'True' if not x then ' my brain makes leap "6 is true, therefore not true..." 'Not 6 is 65529, which is still "true" end if Hope this helps (and makes sense) TTFN - Kent > Why did VB define "False" as "-1" (when it gets converted to other > data types) rather than "1"? > > How is boolean data stored internally? > > Just curious. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.