DAY 040: _TOGGLEBIT

[Pete]

Here is an interesting one for all you bit flipping coders out there...

_TOGGLEBIT

SYNTAX result = _TOGGLEBIT(numericalVariable, numericalValue)

Usage: For cross breeding elephants and rhinos. What's that good for? Eleph-i-no!

Okay, I know bit-flipping can be used somehow to detect a hardware malfunction in a Windows operating system. I would imagine encryption would be another practical use. I also did some reading on using bit-flipping as an alternative to doing string math, but that was a very involved process, so I have no work created to demonstrate how that would be accomplished.

What I can easily see if we flip the first bit, we can get a 0 or 1, which is good for a toggle function.

Now the easiest method to create your own toggle for a program has been demonstrated in this forum numerous times...

toggle = 1 - toggle Mark posted about that one months ago.

So using toggle = 1 - toggle we start out with toggle = 0, hence 1 - 0 = 1. Loop again and 1 - 1 = 0

Now we can accomplish the exact same toggle effect with _TOGGLEBIT, as follows...

Code: (Select All)

DIM a AS INTEGER ' Also avilable are _INTEGER64, LONG, _UNSIGNED, and _BYTE,
DO
    DO
        SELECT CASE a
            CASE 0
                PRINT " Steve is good...";
            CASE 1
                PRINT " Pete is better!": PRINT
        END SELECT
        SLEEP
        a = _TOGGLEBIT(a, 0)
        mykey$ = INKEY$
    LOOP UNTIL mykey$ = CHR$(9) OR mykey$ = CHR$(27)
    PRINT
    FOR i = 0 TO 15
        PRINT i; _TOGGLEBIT(a, i)
    NEXT
    PRINT
LOOP UNTIL mykey$ = CHR$(27)

So maybe this example will goad Steve a "bit" to elaborate on some of his experiences with _TOGGLEBIT. Also, I'd love to hear some comments from @jack about bit-flipping, and his experience with coding decfloat.

Pete

[mnrvovrfc]

This is one keyword that tells me that "AS _BIT" is worthless. Cannot be the return value of a function which turned me off straight away and forced me to use "AS _BYTE" which I don't like neither. Also the other-worldly behavior of "NOT" caused me to reject "AS _BIT".

"_TOGGLEBIT" and the others are just easier, don't even have to declare an array to have up to 64 on/off switches. Now only if we were all more consistent about ON or OFF, ZERO or ONE, TRUE or FALSE, YES or NO, MALE or FEMALE, BLACK or WHITE... maybe not that last one but it could describe some people with one-track minds.

[SMcNeill]

This is one keyword that tells me that "AS _BIT" is worthless. Cannot be the return value of a function which turned me off straight away and forced me to use "AS _BYTE" which I don't like neither. Also the other-worldly behavior of "NOT" caused me to reject "AS _BIT".

"_TOGGLEBIT" and the others are just easier, don't even have to declare an array to have up to 64 on/off switches. Now only if we were all more consistent about ON or OFF, ZERO or ONE, TRUE or FALSE, YES or NO, MALE or FEMALE, BLACK or WHITE... maybe not that last one but it could describe some people with one-track minds.

What're you talking about??  There's no problem with using a BIT as a return value for a Function.

Code: (Select All)

Print foo("True")
Print foo("False")

Function foo` (Truth As String)
    If Left$(UCase$(_Trim$(Truth)), 1) = "T" Then foo = 1
End Function

Is there something I'm missing here?

[SMcNeill]

@Pete Where _TOGGLEBIT can be useful is when you're bitpacking data to save memory usage.  As an old skool programmer (tm), you should be aware of the concept, even if you never used it.

Let's say you're writing a program and TRULY need to preserve memory usage.  Maybe it's got a 10,000,000 record database for customer information associated with it -- THAT could warrant some aggressive memory management!

Now, let's say they have a bunch of boolean data:
HasPhone
AllowsCalls
HasEmail
AllowsEmails
HasPhysicalMail
AllowsPhysicalMail
HasSex
WithPete

Now, you could use 8 variables and store those for a good 100+ bytes of memory usage with each record..

OR...

You could store it all on one byte, but reserving a bit for each value in a single character.

If the user has a phone then UserCompressedData = _ToggleBit(UCD, 1).
The phone breaks: UCD = _ToggleBit(UCD, 1)

Has email?  Togglebit 3.
Loses their password and can't log in?  Togglebit 3.

On/Off toggles stored in bits in a character.  <-  that's what it's for.  

[Pete]

Edit: This was a reply to mn. I was writing this while Steve was posting. My multiple toggle idea is similar to his, apparently, but I haven't coded a database that way before.
-----------------------
I have a two track mind, but getting a train of thought to run on either is darn near impossible these days...

Yeah one of the things that I haven't explored yet is using _TOGGLEBIT to keep track of multiple toggle conditions.

Code: (Select All)

DIM AS INTEGER a, b, c
DO
    INPUT "Press 1 for cat 2 for dog: "; a: a = a - 1: a = _TOGGLEBIT(a, 0)

    INPUT "Press 1 for happy 2 for sad: "; b: b = b - 1: b = _TOGGLEBIT(b, 1)

    INPUT "Press 1 for black 2 for white: "; c: c = c - 1: c = _TOGGLEBIT(c, 2)

    IF _TOGGLEBIT(b, 1) THEN PRINT "happy" ELSE PRINT "sad"
    IF _TOGGLEBIT(c, 2) THEN PRINT "black" ELSE PRINT "white"
    IF _TOGGLEBIT(a, 0) THEN PRINT "cat" ELSE PRINT "dog"
    PRINT
LOOP

Terrible example, but I really can't wrap my 'train' around anything more practical I'd use this with at the moment. (Edit: And then Steve posted his database management example.)

Pete

[mnrvovrfc]

What're you talking about??  There's no problem with using a BIT as a return value for a Function.

But I come from v0.98. Because I don't do as much programming as you, I say something and then you appear to tell me it's wrong. (crying)

Fiddlesticks. "_TOGGLEBIT" is still better toward a single LONG or _INTEGER64 and descriptive constants for which bit, and variable "AS _BIT" for me has died. Have to waste an entire byte anyway only to have a bit for anything.

[SMcNeill]

@Pete -- Try this example out, and maybe it'll help you wrap your head around the function a little better.

Code: (Select All)

Dim As _Byte a

Input "Press 1 for cat 2 for dog: "; userInput
If userInput = 1 Then a = _ToggleBit(a, 0)

Input "Press 1 for happy 2 for sad: "; userInput
If userInput = 1 Then a = _ToggleBit(a, 1)

Input "Press 1 for black 2 for white: "; userInput
If userInput = 1 Then a = _ToggleBit(a, 2)

If _ReadBit(a, 1) Then Print "happy" Else Print "sad"
If _ReadBit(a, 2) Then Print "black" Else Print "white"
If _ReadBit(a, 0) Then Print "cat" Else Print "dog"
Print
Do
    Print
    Print
    Input "Did your pet's mood change? (y/n) =>"; yn$
    If Left$(UCase$(yn$), 1) = "Y" Then a = _ToggleBit(a, 1)
    Print
    Print
    If _ReadBit(a, 1) Then Print "happy" Else Print "sad"
    If _ReadBit(a, 2) Then Print "black" Else Print "white"
    If _ReadBit(a, 0) Then Print "cat" Else Print "dog"
Loop Until yn$ = ""

[Pete]

Well, I already understood the part about dooing a bit flip to change a condition. I'm just saying with the way I would code a similar function vs the way bit flipping works, hasn't convinced me I'd be gaining any performance by using this method. What's good about knowing it exists is I may find some future use for it. I seem to be using SGN() a lot these days, for example.

Pete

[SMcNeill]

Well, I already understood the part about dooing a bit flip to change a condition. I'm just saying with the way I would code a similar function vs the way bit flipping works, hasn't convinced me I'd be gaining any performance by using this method. What's good about knowing it exists is I may find some future use for it. I seem to be using SGN() a lot these days, for example.

Pete

BITs aren't about performance.  In fact, they're very BAD at performance!!  

Imagine these two different scenarios:

1) You have to read a text string into a program.

2) You have to read a compressed string into a program, extract the contents, save them to disk, and then read the text string they produce into your program.

Now, which is going to be faster for you??

---

That's basically what goes on with anytime you're accessing a BIT!

It's stored in (at least) a byte.  So you load that byte in memory.  Peak inside that byte.  Count over to the bit you need information from.  Read in that one bit.  Process it.

Compared to:  Load a byte in memory.  Process it.

Bits are inefficient by their very nature.  Your program will never run faster, or better, by making use of them.

So WHY would you ever want to use them???

The same reason why you'd want to use compressed files -- to reduce overall size and memory usage.  QB64 takes up 700MB or so of disk space.  Yet, when it make it available for downloading, you get it in less than 100MB.  Less space on the servers.  Less size to send across the internet.  

But you still have to unzip that archive before you can make use of it! 

That's basically BITs in a nutshell.  When you need to reduce the size of memory your program uses, you might pack a bit array to compress the amount of memory it uses.  It isn't going to make what you're doing any more EFFICIENT, but it'll reduce the space required to do what you're doing in memory or on your hard drive.

BUT, with 64-bit PCs and everyone having 8GB+ of memory available anymore, how much does one have to actually worry about compressing that memory like they used to?  Honestly, I imagine that in the next 10 years, we'll see various programming languages start to depreciate BIT usage.  I imagine Apple will be the first to decide they're no longer going to offer bit for new versions of whatever they offer developers, and after the outrage and backlash dies down, a few years later, others will follow the trend.

Bits just aren't in vogue as much as they used to be, back when folks were trying to squeeze everything they could out of 64k memory.

[Pete]

Well, I already understood the part about dooing a bit flip to change a condition. I'm just saying with the way I would code a similar function vs the way bit flipping works, hasn't convinced me I'd be gaining any performance by using this method. What's good about knowing it exists is I may find some future use for it. I seem to be using SGN() a lot these days, for example.

Pete

BITs aren't about performance.  In fact, they're very BAD at performance!!  

Imagine these two different scenarios:

1) You have to read a text string into a program.

2) You have to read a compressed string into a program, extract the contents, save them to disk, and then read the text string they produce into your program.

Now, which is going to be faster for you??

---

That's basically what goes on with anytime you're accessing a BIT!

It's stored in (at least) a byte.  So you load that byte in memory.  Peak inside that byte.  Count over to the bit you need information from.  Read in that one bit.  Process it.

Compared to:  Load a byte in memory.  Process it.

Bits are inefficient by their very nature.  Your program will never run faster, or better, by making use of them.

So WHY would you ever want to use them???

The same reason why you'd want to use compressed files -- to reduce overall size and memory usage.  QB64 takes up 700MB or so of disk space.  Yet, when it make it available for downloading, you get it in less than 100MB.  Less space on the servers.  Less size to send across the internet.  

But you still have to unzip that archive before you can make use of it! 

That's basically BITs in a nutshell.  When you need to reduce the size of memory your program uses, you might pack a bit array to compress the amount of memory it uses.  It isn't going to make what you're doing any more EFFICIENT, but it'll reduce the space required to do what you're doing in memory or on your hard drive.

BUT, with 64-bit PCs and everyone having 8GB+ of memory available anymore, how much does one have to actually worry about compressing that memory like they used to?  Honestly, I imagine that in the next 10 years, we'll see various programming languages start to depreciate BIT usage.  I imagine Apple will be the first to decide they're no longer going to offer bit for new versions of whatever they offer developers, and after the outrage and backlash dies down, a few years later, others will follow the trend.

Bits just aren't in vogue as much as they used to be, back when folks were trying to squeeze everything they could out of 64k memory.

Yet, when it make it available for downloading,

All I got from that was... I WANT MY 2 BUCKS BACK!!!

I did bit packing a couple of decades ago, to get my app to fit on a CD-ROM. Worked like a charm, but never used whatever the hell I did back then, since. So still not seeing _TOGGLEBIT in my future, but it was fun to pick it for the list and get some discussion going on.

Pete