Boolean arrays in BBC BASIC

So now I’m using 8 bits where one is relevant. So be it, but it does limit the size of my humongous arrays.

I am intrigued. What are these humongous bit/boolean arrays for? How are the return values used?

I ain’t going to start farting about making workarounds. Life’s too short.

That is the pleasure of programming without pressure. ;-)

Were IF and the similar keywords to only work with strictly boolean values 1 I think there would be less of a problem. The simplification to ‘non-zero’ for ‘true’ makes sense when every byte matters. However, I have seen very similar situations reported for other languages, so it is not only BBC BASIC.

100% agreed with all that.

‘true’ is -1 and ‘false’ is 0 whether integer or float

Strictly speaking this is true. But using float is horrible, because while there is an exact -1 value in BBC BASIC floats, relying on exact values in floats in general is utterly horrible… -0.999999999999999999999999972 isn’t even nearly TRUE…

How are the return values used?

Most of them aren’t, but you don’t know in advance which ones will be and which ones won’t. But it’s far quicker to generate them all and then find the ones you want than to calculate the particular ones you want when you need them, because the calculation is best done sequentially, whereas the use of them is random.

And of course when you do use them, they’re used in conditional statements.

In Lua, zero (0) and the empty string ("" or '' or [[]] or [=[]=] or … ) both count as true. The only non-Boolean to count as false is nil. Transcribing from BASIC, say for the redrawing of windows, you have to be careful to say while win ~= 0 .. rather than the usual trope: while win .. .

I forget entirely how all this is handled in FORTRAN, Algol, Pascal or COBOL.

If you are already using array%?position% to get an 8-bit value, then changing to getting bits or setting/clearing/flipping bits is not too difficult in some functions/procedures.

Something like (this is untested):

DEF FNbool(array%,position%)
bitnumber% = position% AND 111
byte = position%>>3
mask% = 1<<bitnumber%
eightbools% = array%?byte%
value% = eightbools% AND mask% : REM value=0 for FALSE, something else for TRUE
IF value% THEN value%=TRUE : REM Not strictly needed if always compare to FALSE
=value%

DEF PROCsetbool(array%,position%,set%)
bitnumber% = position% AND 111
byte = position%>>3
mask% = 1<<bitnumber%
eightbools% = array%?byte%
IF set% THEN
eightbools% = eightbools% OR mask% : REM Set one bit in eightbools, leave 7 bits same
array%?byte% = eightbools% : REM Stores back
ELSE
eightbools% = eightbools% AND !mask% : REM Invert the mask to clear one bit
array%?byte% = eightbools% : REM Store back
ENDIF
ENDPROC

DEF FNboolsize(size%) : REM calculates how big your DIM should be
extra% = size% AND 111
bytes = size%>>3
IF extra% THEN bytes%+=1
=bytes%

This will obviously save space but will be slower than simply using ? and wasting space. You would have to balance the space saving against the speed difference to see which is the best solution.

The forum has messed up the BASIC. Everywhere where is says AND 111 that is a binary number and should be (percent)111. Or you could use AND 7.

there is an exact -1 value in BBC BASIC floats

And in IEEE floats, all precisions.

The warning above equality of floats is very valid, though.

This will obviously save space but will be slower than simply using ? and wasting space. You would have to balance the space saving against the speed difference to see which is the best solution.

Exactly the balancing act I’ve been playing with, Graeme. Sadly, the extent of the slowerness is such that life is literally too short, so I’m having to compromise on the size of arrays. If it turns out this is a compromise too far, I shall have to bite the assembler bullet. Although I literally wrote the book on AArch32 assembler, I’ve not written much of it in anger – not written huge amounts of assembler since 26-bit days. Desperately out of practice!

Something like (this is untested)

Or this, tested. ;-)

DEFPROCdimBit(RETURN arr%,num%)
 LOCAL i%
 DIM arr% num% DIV 8
 FOR i%=arr% TO arr%+num% DIV 8:?i%=0:NEXT i%
ENDPROC
DEFPROCsetBit(arr%,bit%)
 arr%+=bit% DIV 8
 ?arr%=?arr% OR 1<<bit% MOD 8
ENDPROC
DEFPROCunsetBit(arr%,bit%)
 arr%+=bit% DIV 8
 ?arr%=?arr% AND NOT 1<<bit% MOD 8
ENDPROC
DEFFNgetBit(arr%,bit%)
 arr%+=bit% DIV 8
=-SGN(?arr% AND 1<<bit% MOD 8)
REM omit -SGN if only non-zero required

Edit: corrected a bad mistake in the FOR..NEXT ;-(

Sadly, the extent of the slowerness is such that life is literally too short,

The routines I posted can be a little faster using shifts instead if DIV|MOD, at the expense of clarity.

It looked as though you needed multi-dimension arrays. It that a fixed number?

Apart from the fact that I inlined it for speed (and because the number of instances was small, albeit in heavily used loops), that’s broadly what I did. But it’s too slow, sadly. Far too slow…

But why DIV 8 rather than >>> 3?

Edit: crossed in the post! 8~)

It that a fixed number?

3-dimensional, but all three dimensions are of variable size.

Well, there’s a 2-dimensional one as well, but that’s far smaller – perfectly manageable.

I’ve not written much of it in anger – not written huge amounts of assembler since 26-bit days. Desperately out of practice!

The assembler for this is pretty straightforward and I have done this for Basalt. Here is a crude routine to substitute for FNgetBit above to get you started. ;-)

DEFPROCassBit
 DIM C% 63
 FOR F%=0 TO 2 STEP 2
 P%=C%
 [OPT F%
 .getBit
 ADD      r0,r0,r1,LSR#3;       arr%+=bit% DIV 8
 LDRB     r0,[r0];              ?arr%
 MOV      r2,r1,LSR#3;          bit% DIV 8
 SUB      r1,r1,r2,LSL#3;       bit% MOD 8
 MOV      r2,#1;                constant
 AND      r0,r0,r2,LSL r1;      ?arr% AND 1<<bit%
 TEQ      r0,#0;                false?
 MVNne    r0,#0;                set true
 MOV      pc,lr
 ]
ENDPROC
DEFFNgetBit(A%,B%)
=USRgetBit

Add a few MUL|MLA for multi-dimensions. If you want more polish and flexible calling I might have something.

I feel like I’m getting (a very friendly) prodding here! 8~)

That doesn’t look any different from good ol’ 26-bit assembler, does it!

If once I start doing this in assembler, practically the whole project will end up in assembler, with just the wimp handling in BASIC…

For what it’s worth, I know how to do all this in assembler (although I would have to get my brain back into gear). Not sure I can be bothered, but I might if I find I want bigger arrays than I can do with bytes and indirection operators. What I was really bemoaning was the lack of boolean arrays in BASIC, or even byte arrays – but if I’m the only one who’d use them, what’s the point? Others might be less willing than I am to use assembler, but if there aren’t any such others, who cares?

It’s much better to check if something isn’t FALSE

Sophie herself seems to prefer IF ... <> 0 THEN (source: ChangeFSI). This means that the variable can be more values than just TRUE or FALSE, and… I’ll patiently wait for Steve to come along and explain how even though FALSE is tokenised, it’s quicker to use zero. ;-)

but I am amazed at all this fuss over battles lost and won many decades ago.

Because roughly every five weeks, somebody has a “cool new idea” for a programming language, and about every five years, one turns up that people start using. So the battles of yesterday get to be fought all over again, but with shiny rounded corners applied. ;-)

First, you need a separate datatype for Booleans

It would make sense, though I have a horrible feeling the BOOL in C is just a typedef for an integer of some sort. I’ve not checked, I don’t want to be disappointed.

Another issue (and one that relates to the “always test against FALSE” concept) is that in the absence of a specific boolean type that can literally have only two values, we risk ending up with data that is not FALSE but equally is not TRUE as well.

Second you need a clearly defined coercion from other types to Booleans, if you want to be able to express things like if a then b = (c and d) or e when the values in question may not be themselves Booleans (Icon’s big lesson).

This is how we end up with weirdness like == and === in PHP. The first tests for equality (if an int is -1 and a real is -1 then they’re both equal), while the second tests for exactitude, that is to say that we need to have the values not only being the same, but the variable types too. Which is interesting given that PHP plays fast and loose with its variables.

Third, you need a proper discrimination between bitwise and logical operations (& versus && etc in C) which should be eager and lazy respectively.

Well, yes. One is a “this AND that” while the other is a way of fiddling bits. They are only “the same thing” because of how binary maths works, and even then, not always, because of how binary maths works. ;-)

I am just amazed that so many programmers could write tens of thousands of programs with such a mess to work with.

We were inventive and we made do. Look at how many programs for lesser eight bit machines are a mass of PEEK and POKE to get stuff done. Once upon a time, the programmers of the day know what all this meant (like CALL &FFF1, perhaps? ;-)) but when viewed today, it might come across as something between gibberish and applied magical incantations.
Don’t get me started on the underlying mess that is “any Wimp program written in BASIC”.

But, we had to make do within the limits of the system. So our BASIC has no byte array? No biggie. It has DIM and it has ?, so what more d’you need? :-)

Were IF and the similar keywords to only work with strictly boolean values I think there would be less of a problem.

That would be a ridiculous problem. How would you deal with “IF screenwidth% < 480 THEN ...”?

Maybe what you’re thinking of is having IFF flag% = TRUE THEN ... where IFF deals with equality on a strictly “this happens if and only if the clauses are precisely equal”.

I have seen very similar situations reported for other languages

Yes, because it is useful.

One that I use a fair amount in C is a construct like:

if ( flag )
{
   ...do stuff...
}

Which is understood by the compiler to be “when flag is not zero”, so one can define FALSE to be zero, and anything else will be NOTFALSE (as opposed to specifically TRUE, which I define as ‘1’).

The inverted case is easy, if ( !flag ) which translates to be “when not (flag is not zero)” (in other words, when the flag is zero).

But using float is horrible

Not just the lack of exact values, there’s also all the processing overheads in coercing your TRUE to be a float, and fudging it every time a comparison is required.
Nobody should ever use a float/real/double/etc to store a flag.
If anybody here should do such a thing, don’t own up. Because it’s the kind of wrong that demands a cartoon anvil be dropped upon your head from a great height.

In Lua, zero (0) and the empty string ("" or ’’ or [[]] or [=[]=] or … ) both count as true.

What? Zero is true? What weirdo came up with that idea?

It’s a rhetorical question, as I note that you have at least four ways to specify an empty string, one of which looks like an emoji (Janus?).

using shifts instead if DIV|MOD, at the expense of clarity.

I find the shifts clearer…

That doesn’t look any different from good ol’ 26-bit assembler, does it!

Why d’you think RISC OS is running in a 32 bit world and we’re debating (endlessly) what to do about the 64 bit stuff?

With the exception of mucking around with the PSR (pushing values into R14 and TEQPing stuff into PC, etc etc), 32 bit code is pretty much exactly the same as 26 bit code.

Take a look at https://heyrick.eu/blog/index.php?diary=20201003
It’s a program designed to dump out the MEMC’s CAM table. It was written and assembled on a Pi, and works on Arthur, right back to the initial 0.30 release. It will also run on the Pi, where it’ll tell you that it’s the wrong sort of machine.

but if I’m the only one who’d use them, what’s the point?

It’s not that you’d be the only one to use them, it’s more like we’ve all had four decades of coming up with alternatives…

Nobody should ever use a float/real/double/etc to store a flag.

Amen.

That doesn’t look any different from good ol’ 26-bit assembler, does it!

Why d’you think RISC OS is running in a 32 bit world and we’re debating (endlessly) what to do about the 64 bit stuff?

Er well yes. Rhetorical unquestion; I did assume that given my history that might be obvious!

it’s more like we’ve all had four decades of coming up with alternatives…

I wasn’t sure about that, given that I didn’t think it’s that common to want huge arrays of booleans, and while using 32-bit ints for booleans is a bit manky, it’s not hard to make it work.

You’ve got to remember BASIC is a beginners language, which is why it only has 3 data types (int, float and string), once you start introducing lots of extra types (boolean, 32 and 64 bit integers, IEEE floats and doubles; mentioned already), it starts moving away from beginner, and you really need to consider if it isn’t time to put your big boy pants on and try a grown up language.

I didn’t think it’s that common to want huge arrays of booleans

For what value of “huge”? If you have more than, say, thirty flags, surely there’s a point where one has to wonder “am I holding it wrong”?

put your big boy pants on and try a grown up language.

You forgot signed and unsigned.
Oh, whoops, that -1 is now “a very big number”.

Dear David

I grew out of caring tuppence about whether it’s a “beginners’ language” or not years ago. I gave up professional programming four decades ago and have no intention of starting again. I know BASIC well because I used it a lot in education; I know ARM assembler because I had RISCOS machines from the day they first appeared and found it useful, and ended up working for ARM writing the documentation of the ARM instruction set and assembler. Retired from that in 2007 after the publication of the ARMv7 ARM ARMs.

The “grown-up” languages I used four decades ago are history, and I don’t like C, it’s an ugly language.

If you have more than, say, thirty flags, surely there’s a point where one has to wonder “am I holding it wrong”?

I’m not really thinking about them as flags, I have to say. More like “this point in 3-space exists, this one doesn’t.” But think about a three dimensional array of one-bit values measuring around a few hundred to a thousand or so points in each dimension.

Equality has always been a dodgy notion, not just in computer science but in mathematics also. Is the integer 0 the same as the rational number 0? We denote them by the same symbol, but so what? There are lots of mathematicians who see elements of sets as tagged by that set, so that you have to have explicit inclusion functions to change the tag.
Category theorists, algebraic topologists, … would insist on this because the sloppy coercions of the old days just do not work. Haskell deals with it by having a type-class Eq. The dodginess comes down in the end to human psychology, and our belief that the universe has to conform to our prejudices. Here is how you derive equality of lists of things of type a ([a]) once you have a notion of equality for values of type a.

instance Eq a => Eq [a] where
    []     == []      = True
    []     == (y:ys)  = False
    (x:xs) == []      = False
    (x:xs) == (y:ys)  = x == y && xs == ys

The “grown-up” languages I used four decades ago are history, and I don’t like C, it’s an ugly language.

Out of the current top 10 most popular languages, only 1 © was around when I started programming a mere 40 years ago. There’s a whole new bunch of grown up languages now.

There’s a whole new bunch of grown up languages now.

I quite believe you, but I’m an old git and I’ve had enough of learning whole new languages. Extensions to languages I know, no problem. I doubt resuscitating any of my 1960s or 70s languages is worth the effort, so it’s BBC BASIC or ARMArch32 assembler for me. If I have to live with the limitations of that, so be it. Nothing I’m doing matters a damn to anyone else anyway.