True and false or 1 and 0 in arrays

Getting Started
1

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?

2

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.

3

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
4

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
5

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!

6

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.

7

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

8

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
9

I disagree with ā€žbit twidfling times are overā€œ w/o knowing what large means.

10

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"