Jump to content
Sign in to follow this  
hloberg

Use of NOT in BASICs

Recommended Posts

I'm glad a separate thread is being created since I think the topic of who wrote TI BASIC is important, and we don't want to start modifying websites and other information without more information than we already have.

 

I'm also a proponent of keeping threads on topic, so to put this one back on topic:

 

The problem with the term *NOT* is that there are multiple interpretations.  In spoken language it generally means "do the opposite", and that is probably the first representation most people learn.  I don't know if mathematics has a definition for the term, but personally I like the way the TMS9900 assembly language avoids using *NOT* in favor of instructions that, to me, seem more precise:

 

Negate (NEG) is a mathematical operation, and does what you expect when you put a minus-sign in front of a number, variable, or expression.

 

Invert (INV) is a binary operation and changes all one-bits to zero, and zero-bits to one (also known as the *complement*).  In languages like C this is achieved with the tilde (~) operator.

 

If you want to know if a number is zero, or some other value, you should explicitly write the comparison: IF A==0 THEN, or IF A <> 0 THEN, etc.  None of this: IF A THEN ... crap.  Drives me nuts.

 

The idea of NOT as applied to a number, variable, or expression is ambiguous and does not have a place in programming languages IMO (unless the language has a native boolean type that can only ever be true/false or 0/1).  I really dislike the idea that *any value* other than zero is considered true.  Why would you have almost an unlimited number of possibilities to represent TRUE, but only one way to represent FALSE?

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Give up?:-D

 

     

Spoiler

Looks like you were right in the first place...

 

Set theory

There is an isomorphism between the algebra of sets and the Boolean algebra, that is, they have the same structure. Then, if we map boolean operators into set operators, the "translated" above text are valid also for sets: there are many "minimal complete set of set-theory operators" that can generate any other set relations. The more popular "Minimal complete operator sets" are {¬, ∩} and {¬, ∪}. If the universal set is forbidden, set operators are restricted to being falsity- (Ø) preserving, and cannot be equivalent to functionally complete Boolean algebra.

 

Share this post


Link to post
Share on other sites

NOT(x) := NAND(x,x)

AND(x,y) := NOT(NAND(x,y))

OR(x,y) := NAND(NOT(x),NOT(y))

  • Like 2

Share this post


Link to post
Share on other sites
On 8/25/2019 at 12:05 PM, HOME AUTOMATION said:

Give up?:-D

 

     

  Hide contents

Looks like you were right in the first place...

 

Set theory

There is an isomorphism between the algebra of sets and the Boolean algebra, that is, they have the same structure. Then, if we map boolean operators into set operators, the "translated" above text are valid also for sets: there are many "minimal complete set of set-theory operators" that can generate any other set relations. The more popular "Minimal complete operator sets" are {¬, ∩} and {¬, ∪}. If the universal set is forbidden, set operators are restricted to being falsity- (Ø) preserving, and cannot be equivalent to functionally complete Boolean algebra.

 

my brain just exploded. 🤪

  • Like 1

Share this post


Link to post
Share on other sites

I should have posted the link to that segment, it was: functional completeness

 

I'll join you...

 

images.JPG.80a6d71ee3b4ce44f1c3197dac1c320a.JPG       images2.jpg.725c3e51d2f7dc0f285bc610cb1e32f1.jpg

 

...it all seems to lead into Quantum logic gating. I wish I had some inductive insight to offer on that, beyond being... here there and everywhere. I'm sure someone here does... Think qubits.

 

CSWAP sounds like an assembly mnemonic.:-D

Edited by HOME AUTOMATION
wrong Link
  • Thanks 1

Share this post


Link to post
Share on other sites

NOT(a) := NOR(a,a)

AND(a,b) := NOR(NOT(a),NOT(b))

OR(a,b) := NOT(NOR(a,b))

 

For every boolean function there is a composition of (multiple) AND, NOT, OR that produces the same truth table (i.e. which is functionally equivalent).

  • Like 3

Share this post


Link to post
Share on other sites
5 hours ago, mizapf said:

NOT(a) := NOR(a,a)

AND(a,b) := NOR(NOT(a),NOT(b))

OR(a,b) := NOT(NOR(a,b))

 

For every boolean function there is a composition of (multiple) AND, NOT, OR that produces the same truth table (i.e. which is functionally equivalent).

whats the difference between NOR & XOR. been a while since college

Share this post


Link to post
Share on other sites
15 hours ago, HOME AUTOMATION said:

I should have posted the link to that segment, it was: functional completeness

 

I'll join you...

 

images.JPG.80a6d71ee3b4ce44f1c3197dac1c320a.JPG       images2.jpg.725c3e51d2f7dc0f285bc610cb1e32f1.jpg

 

...it all seems to lead into Quantum logic gating. I wish I had some inductive insight to offer on that, beyond being... here there and everywhere. I'm sure someone here does... Think qubits.

 

CSWAP sounds like an assembly mnemonic.:-D

Jump to search

Notation in article: 

Reversible computing is a model of computing where the computational process to some extent is time-reversible.

does that mean if you make the wrong computations you erase yourself from having ever existed? 😕

Share this post


Link to post
Share on other sites
35 minutes ago, hloberg said:

whats the difference between NOR & XOR. been a while since college

 

NOR is the opposite of AND OR, i.e., the result is TRUE if both operands are FALSE, else, FALSE:

A NOR B = R
--------+--
1     1 | 0
1     0 | 0
0     1 | 0
0     0 | 1

XOR results in TRUE only when the operands differ:

A XOR B = R
--------+--
1     1 | 0
1     0 | 1
0     1 | 1
0     0 | 0

 

...lee

  • Like 5
  • Thanks 1

Share this post


Link to post
Share on other sites

XOR has an interesting property; it can be used as a switchable NOT.

 

XOR(a,0) = a

XOR(a,1) = NOT(a)

 

XOR(.,b) is reversible (for every constant b) by itself: it is its own inverse. This is true in B={0,1} and also B^n (with bitwise XOR). This follows from the above observation.

 

XOR(XOR(a,b),b) = id(a) = a

 

Other reversible operations are permutations (because they only change the order of the elements). Thus, if you combine arbitrary many XORs with permutations, you get a reversible function that operates on every bit of the value and changes them in non-obvious ways. Take a secret value as b and derive permutations from it, and you have a symmetric cipher.

  • Like 3

Share this post


Link to post
Share on other sites
3 hours ago, hloberg said:

Jump to search

Notation in article: 

Reversible computing is a model of computing where the computational process to some extent is time-reversible.

does that mean if you make the wrong computations you erase yourself from having ever existed? 😕

computing... computing... computiiinnnnnnggggggggg... ............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................:sleep:

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites
On 8/23/2019 at 1:20 AM, Vorticon said:

I'm not too clear on this. Ord(integer) = integer, right? 

Yes. But UCSD Pascal has the speciality that the logic functions will render bitwise results if you use the ord( ) function on the parameters. If you don't, only the least significant bit is considered. That's the same as if you use a standard boolean, which uses only one bit in a 16-bit word.

  • Like 1

Share this post


Link to post
Share on other sites
On 8/25/2019 at 1:23 AM, matthew180 said:

I really dislike the idea that *any value* other than zero is considered true.  Why would you have almost an unlimited number of possibilities to represent TRUE, but only one way to represent FALSE?

Unless you use the trick with ord( ), UCSD Pascal represents false by 0 and true by 1. But in systems like TI BASIC, where the operation NOT is performed by an INV on the whole 16 bit word, which is used to store the variable, you do get the characteristics that 0 is false and anything that's not false must be true. Hence false is really 0 and not(0) = 0xFFFF. Which in two's complement evaluates to -1. This also leads to the confusing fact that 4 is considered true, but not(4) is also true, as it evaluates to -5, which isn't 0.

Hence it's really so that there's only one intentional value for false, and one for true. But if you evaluate a value to be true or false, and do consider all 16 bits, then you have to do something about the other 65534 possible values too. The simplest thing you can do is considering everything that's not zero to be true.

Edited by apersson850
  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
On 8/24/2019 at 4:23 PM, matthew180 said:

I really dislike the idea that *any value* other than zero is considered true.  Why would you have almost an unlimited number of possibilities to represent TRUE, but only one way to represent FALSE?

You should actually love it - it's a direct link into assembly. ;) Pretty much all CPUs calculate equality with a single bit that compares a value to 0. In assembly, zero is equivalent to equal. If you compare two values, the ALU subtracts them and then runs the result through that zero test to set the EQUAL bit. Thus, zero is equal and everything else is not equal.

 

That concept is one of the few that made its way into languages without being too badly distorted, the difference being only that they changed the concept from "EQUAL" to "TRUE". If you compare equality, in fact, it's equivalent.

 

IF A=B THEN BLAH is the same as C @A,@B / JEQ BLAH
 

Now, it's super common practice in assembly to test for zero or not zero by checking the equal bit without doing any actual compare operation. You can use the result of a previous operation, or just do something that sets the flags like a move to itself. Thus:

MOV R0,R0 / JNE BLAH maps exactly to IF R0 THEN BLAH

So likewise, NOT maps pretty directly...

IF NOT R0 THEN BLAH  ---  NOT R0 / JNE BLAH

The only real annoyance (to me at least) is that the assignment to "true" sort of inverts the default case... since TRUE is not zero, you usually need to check the equal bit is NOT set to get the same semantic result. I'm used to testing for equal (so, zero) being my default test in assembly. I wonder if that's just a mindset thing...

I don't think, at least originally, that it was deliberately designed that way so much as the language eventually had to boil down to an assembly comparison of some sort, and it turned out that whatever you ended up loading there could be tested in the same manner. People liked it so it stayed. They must like it, I think almost every language allows for it.

 

  • Like 4
  • Thanks 2

Share this post


Link to post
Share on other sites
On 8/24/2019 at 4:23 PM, matthew180 said:

I'm glad a separate thread is being created since I think the topic of who wrote TI BASIC is important, and we don't want to start modifying websites and other information without more information than we already have.

 

I'm also a proponent of keeping threads on topic, so to put this one back on topic:

 

The problem with the term *NOT* is that there are multiple interpretations.  In spoken language it generally means "do the opposite", and that is probably the first representation most people learn.  I don't know if mathematics has a definition for the term, but personally I like the way the TMS9900 assembly language avoids using *NOT* in favor of instructions that, to me, seem more precise:

 

Negate (NEG) is a mathematical operation, and does what you expect when you put a minus-sign in front of a number, variable, or expression.

 

Invert (INV) is a binary operation and changes all one-bits to zero, and zero-bits to one (also known as the *complement*).  In languages like C this is achieved with the tilde (~) operator.

 

If you want to know if a number is zero, or some other value, you should explicitly write the comparison: IF A==0 THEN, or IF A <> 0 THEN, etc.  None of this: IF A THEN ... crap.  Drives me nuts.

 

The idea of NOT as applied to a number, variable, or expression is ambiguous and does not have a place in programming languages IMO (unless the language has a native boolean type that can only ever be true/false or 0/1).  I really dislike the idea that *any value* other than zero is considered true.  Why would you have almost an unlimited number of possibilities to represent TRUE, but only one way to represent FALSE?

From a GPL perspective of speed for XB the line

IF A THEN

will operate much faster then

IF A==0 THEN

or

IF A<>0 THEN

 

Anytime there are more values & symbols to load and compare it slows XB or TI Basic.

Assembly it would almost be no speed difference but it is there if repeated enough times.

  • Like 1

Share this post


Link to post
Share on other sites
On 8/30/2019 at 5:19 PM, apersson850 said:

Yes. But UCSD Pascal has the speciality that the logic functions will render bitwise results if you use the ord( ) function on the parameters. If you don't, only the least significant bit is considered. That's the same as if you use a standard boolean, which uses only one bit in a 16-bit word.

Ah... Fascinating little bit of info here. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...