True and false or 1 and 0 in arrays

I need a large array of things that are either true or false

Is it better for speed and space to use booleans with true and false or integers with 1 and 0 or does it really make no difference?

What is “large”?
If it’s really large, you can use a MemoryBlock and set and check the bits. This is maybe faster as an array.

My experience:

I consider the use of an integer to be the backing for a boolean to be wasteful of memory.
You can hold a boolean in one bit, but getting the value in or out is expensive since the underlying memory is still 64bit integer and needs logical AND /OR to get the value

You dont say HOW large an array
Use an array of booleans for speed regardless of memory

If you want to save memory, set up a memoryblock of (n) bytes in size, and store 0 or 1 in those
Access them using mymb.byte(x) in the same way as you would an array
It may be a bit slower than an array of booleans, but you dont say how fast or slow it needs to be. :slight_smile:

Oh, and having made some apps that started life as ‘this can be true or false’, I later found cases where a third or 4th condition was useful.
Future proofing for that suggests use an integer type, since you can later extend from
x = 1 or x = 0
to x = (any value up to 255 for example)

1 Like

The days of bit twiddling are over. A boolean takes up a single byte, 8 bits. Even for an array of 10 million booleans, I wouldn’t try to pack them 8 to a byte. Code clarity trumps memory compression in this case. Keep it simple, use an array of booleans.

6 Likes

Thanks for those opinions. I’m not thinking of arrays in the millions and so far my Macs are coping OK, although my desktop iMac is getting quite elderly and the app I’m working on is growing like Topsy.
Only enough, Jeff, I had just opted for booleans when I suddenly realised there would be occasions when the things I’m using could be both one thing and the other, like quantum particles, I suppose, so I could do with a 2 as well as a 0 and a 1. Maybe I’ll revert to integers while I still can!

I don‘t agree. This is about knowing your data. And because I don‘t know what Steve‘s data is for, I‘ve asked what large means. Maybe it doesn‘t matter for a few thousand array items; if you have to store and reload 10 million values you‘re in another situation.

And those booleans, if stored to an SQLite database, take zero bytes each.

Oops, I meant to type “oddly enough” not “only enough” or maybe it was one of those useful input correction features, but I can’t seem to edit it now. I’m not sure who you are disagreeing with, Carsten. I only have a few hundred array elements in mind, big enough for me, not even thousands, which seems to be nearly nothing by modern standards, I just wanted to avoid wasting memory and processor time as a matter of good practice, but I suppose it doesn’t matter any more at these levels. When I first started programming, in machine code on a Sinclair ZX80, I could get a Space Invaders game or a disassembler into fewer than 700 bytes, so just ignore me, I’ll soldier on with my little app.

1 Like

I disagree with „bit twidfling times are over“ w/o knowing what large means.

I disagree with “The days of bit twiddling are over.” just because it’s not really true. APIs for instance are full of bit fields. But I agree that for an array, an array of booleans may reach an average point in speed/size.

You can do indexed things directly as

Var flag() As Boolean

For i As Integer = 0 to 9999
  flag.Add(i mod 11 = 0)
Next

flag(1234) = True

flag(88) = not flag(1234)

If flag(33) Then System.DebugLog "flag 33 is True"