Atari BASIC: NOT vs. <>

[dukdukgoos]

Is there any difference (speed, memory efficiency, etc.) between the NOT keyword vs <> operators?

 

10 IF  NOT A=10 THEN something

vs

10 IF A<>10 THEN something

Edited July 12, 2019 by dukdukgoos

[Rybags]

In some cases, NOT can be a timesaver.

Example can be to change a value that's expected to be 0 or 1 to it's opposite.

 

A quick test - it seems the case of using NOT as you present it should be somewhat faster.

 

But another case - IF A<>9 THEN something

vs

IF NOT A<>10 THEN something

the first one wins.

 

Memory wise, NOT A=10 should cost more than A<>10 as there's 2 operators vs 1 (the <> test would be represented in a single byte)

 

It might be worth running some benchmarks - the additional consideration is that a failed test should be quicker than successful since the subsequent <something> isn't executed.

 

The way I benchmarked is to just do 1000 repetitions - you could probably get away with 500 or less:

10 A=10
20 POKE 20,0:POKE 19,0
30 FOR L=1 TO 1000
40 IF  NOT A=10 THEN F=1
50 NEXT L
100 T=PEEK(20)+PEEK(19)*256
110 ? T

[ChildOfCv]

I won't stake my life on it, but I will lean strongly towards "more operations is slower".  This is interpreted BASIC we're talking about, right?  So, not only does it have to evaluate the A=10 part, but then it adds on the token to function call operation of "NOT", which itself probably has to type check the accumulator before evaluating it.  The other form, A<>10, already has the answer by the time it has evaluated the A vs 10 part.  '<>' shouldn't take appreciably more time than '='.

Now, for compiled BASIC with optimization, I'd expect both to take the same time.

[Rybags]

Likely there'd be mixed results, but with Basic it's worth experimenting to grab those few % points of extra speed.

 

NOT is a pretty handy operator since it's just inverting a boolean quantity - and Atari Basic's boolean evaluation assumes any nonzero value as 'true'.

 

The IF/THEN processing is just evaluating a bunch of conditions and converting to boolean, then applying whatever AND/OR conditions might be included.

So, if you can keep things to just mainly those boolean operations it runs a bunch quicker.

 

A good example is fire button processing:

IF NOT STRIG(0) THEN something

should be quicker than

IF STRIG(0)=0 THEN something

 

The next step though can be to just eliminate the IF/THEN altogether and just use the boolean operations in your calculations.

Edited July 12, 2019 by Rybags

[dukdukgoos]

Benchmarking it does indeed show <> is slightly faster than NOT. Makes sense as it's 1 operation vs 2.

 

Thanks all!

[ChildOfCv]

5 hours ago, Rybags said:

Likely there'd be mixed results, but with Basic it's worth experimenting to grab those few % points of extra speed.

 

NOT is a pretty handy operator since it's just inverting a boolean quantity - and Atari Basic's boolean evaluation assumes any nonzero value as 'true'.

 

The IF/THEN processing is just evaluating a bunch of conditions and converting to boolean, then applying whatever AND/OR conditions might be included.

So, if you can keep things to just mainly those boolean operations it runs a bunch quicker.

 

A good example is fire button processing:

IF NOT STRIG(0) THEN something

should be quicker than

IF STRIG(0)=0 THEN something

 

The next step though can be to just eliminate the IF/THEN altogether and just use the boolean operations in your calculations.

Hmm.  I would expect both of those STRIG tests to be nearly the same.  Both are two ops:  1) Get STRIG, then NOT value.  Or 2) Get string, then compare with 0.  Both would have the same responsibility to store the result as a boolean into the accumulator.  Any difference in speed would be due to the different code along either path.

 

Well, if NOT were implemented as a comparison to 0, then it would be slightly slower because it has to set up the 0 for RHS and then call the equality test function.

 

Well, on the third hand, that's 3 tokens to interpret for the NOT case vs 4 for the second case.  So if NOT is faster, then that is the likely reason.  After all, the first test is 4 tokens for the NOT case vs 3 for the direct test case.

[thorfdbg]

11 hours ago, dukdukgoos said:

Is there any difference (speed, memory efficiency, etc.) between the NOT keyword vs <> operators?

 

10 IF  NOT A=10 THEN something

vs

10 IF A<>10 THEN something

Not much, really.  As far as the function is concerned, both work alike. The first takes two operators to evaluate, the second takes only one operand. Thus, as far as timing is concerned, the second should be faster. Probably not noticably faster, but a tiny bit faster.

[Sikor]

there is some differences between than.

NOT - use it in precalculated thing (if NOT A - use when program know A value, result is "0" or "1",  real boolean operetar)

A<>something - when program calculate A value near before this

Sentense "<>" calculate value of the expression

NOT - only compare it

So, in sentense:

NOT A=SOMETHING - first program compare it (NOT) and second try, then value is exactly with quantity, so - here is two operation apart one on "<>".

After compilation probably will be same result.

[thorfdbg]

1 hour ago, Sikor said:

there is some differences between than.

 

Err. There is one thing I got wrong, and that is the operator binding. "NOT" binds stronger than <>. So "NOT A = B" is identical to "(NOT A) = B", though the OP probably meant "NOT (A=B)".

 

But other than that, they all calculate expressions, though probably not the one intended.

[+Stephen]

Not to derail the topic, but I have a question.  Does anybody know why the Rev A BASIC would crash (at least on my 400 with 48kB, bought in 1982) when trying to execute:
? A = NOT B

 

I believe this was a documented bugfix for Rev B

[Nukey Shay]

= and NOT are conflicting comparison operators in such a case.

Use ? A = (NOT B) instead.

[+Stephen]

But - this did not produce an error, it actually locked up the computer hard.

[Rybags]

Likely covered in https://atariage.com/forums/topic/242807-atari-basic-bug-list/

 

 

Surprising how many early rev bugs caused lockups or corruption though they were generally way easier to avoid than the dreaded move memory problem.

[Nukey Shay]

On 7/12/2019 at 8:34 PM, Stephen said:

But - this did not produce an error, it actually locked up the computer hard.

A robot was programmed to believe that it liked herring sandwiches, and a sandwich was placed in front of it. Whereupon the robot thought to itself, "Ah! A herring sandwich! I like herring sandwiches." It would then bend over and scoop up the sandwich in its scoop, straighten up, and in so doing cause the sandwich to slip straight back off the scoop and fall on to the floor. Whereupon the robot thought to itself, "Ah! A herring sandwich…"

 

Replace the robot with Atari Basic, the herring sandwich with the line of code it is attempting to parse, and the poorly-designed scoop for the combination of = and NOT following one another.  No error code generated...it's too busy trying to get ahold of that tasty sandwich.

[Rybags]

That could just about also apply to the 6502 lockup $x2 bug.

[Synthpopalooza]

Or the old Star Trek logic puzzle:

 

Everything I say is a lie.

I am lying now.

Do you believe me?

 

[Synthpopalooza]

As for not operators ... this:

 

GOTO 400*NOT STRIG(0)

 

Always beats this:

 

IF NOT STRIG(0) THEN 400

 

Just be careful about renumbering.

Edited July 14, 2019 by Synthpopalooza

[thorfdbg]

These two are not doing the same. The first always branches, either to line 0 or to line 400, and the second branches to line 400, or continues with the next line. So hardly comparable. Given that the first one even includes a multiplication - which is slow on the math pack - I even doubt that it is faster.

[ChildOfCv]

10 hours ago, Synthpopalooza said:

Or the old Star Trek logic puzzle:

 

Everything I say is a lie.

I am lying now.

Do you believe me?

 

Not the same.  That bug causes permanent destruction of the computer with sparks and smoke.

 

7 hours ago, thorfdbg said:

These two are not doing the same. The first always branches, either to line 0 or to line 400, and the second branches to line 400, or continues with the next line. So hardly comparable. Given that the first one even includes a multiplication - which is slow on the math pack - I even doubt that it is faster.

It's also not portable.  IBM BASIC, for one, does not allow computed GOTOs.  You're stuck with indexed ones, if not literals.

[Rybags]

Plenty of Basics don't allow computed branches as such.  C= is one of them.

Sometimes it's because of optimisation where the address is stored, but in the C= case I think it's just a case of the statement expecting a numeric constant.

[JamesD]

10 minutes ago, Rybags said:

Plenty of Basics don't allow computed branches as such.  C= is one of them.

Sometimes it's because of optimisation where the address is stored, but in the C= case I think it's just a case of the statement expecting a numeric constant.

I think all Microsoft BASICs are like this.  I looked at what it would take to add computed branches (GOTO variable) to the MC-10.  It would be relatively easy to look up the value of a variable, convert it to a 16 bit int, and then search for that line number.  The key difference, is recognizing the first non-space character after the GOTO or GOSUB is a letter rather than a number, and you have to make sure it's not a string variable.  But this would make the interpreter larger, and a lot of things Microsoft did were due to size.
 

[fujidude]

On 7/14/2019 at 12:43 PM, Synthpopalooza said:

Or the old Star Trek logic puzzle:

 

Everything I say is a lie.

I am lying now.

Do you believe me?

 

In order to believe him, what he has been said must be true.  To be true, it must be true in its entirety.  The two statements are logically contradictory and therefore cannot both be true.  Thus, I find it him unbelievable.  I don't understand why that would be considered puzzling.

 

[ChildOfCv]

7 minutes ago, fujidude said:

In order to believe him, what he has been said must be true.  To be true, it must be true in its entirety.  The two statements are logically contradictory and therefore cannot both be true.  Thus, I find it him unbelievable.  I don't understand why that would be considered puzzling.

 

Really, the "This statement is a lie" part should be sufficient on its own, because if the statement is true then it is false.

But still, the fact that it caused the robot's head to explode just revealed how much the 60's generation trusted computers.

[fujidude]

1 minute ago, ChildOfCv said:

Really, the "This statement is a lie" part should be sufficient on its own, because if the statement is true then it is false.

But still, the fact that it caused the robot's head to explode just revealed how much the 60's generation trusted computers.

Beyond just answering the question of if he should be believed; I evaluate it to conclude the 1st statement is false, and the 2nd one is true.  The condition that fits is that he sometimes lies and sometimes tells the truth.  So the 2nd statement is true that the 1st statement is false.

 

[ChildOfCv]

4 minutes ago, fujidude said:

Beyond just answering the question of if he should be believed; I evaluate it to conclude the 1st statement is false, and the 2nd one is true.  The condition that fits is that he sometimes lies and sometimes tells the truth.  So the 2nd statement is true that the 1st statement is false.

 

Exactly, which is why they should have just fed it a self-contradictory statement on its own, rather than beginning with all the irrational theatrics and ending with it.  And actually, (this is from memory, so I could be wrong...), what finally broke the machine was when Mudd simply stated "I am lying."

Edited July 17, 2019 by ChildOfCv