There are, however, some math forums out there. You might go try your hypothesis out on those forums and see what kind of feedback you get and then come back and let us know what you found. You're right, it might be interesting and educational -- and perhaps in ways that we can't even guess right now.

 

I dunno how useful it is, probably not at all, but it's interesting never-the-less.

Anyways, here's a solution I've found!

If you consider all odd #'s as 1/HIGH/TRUE and all even #'s as 0/LOW/FALSE then all boolean functions can be performed via ordinary algebraic functions as follows:

NOT(A) = A +/- 1
XOR(A,B) = A +/- B
XNOR(A,B) = A +/- B +/- 1
AND(A,B) = A * B
NAND(A,B) = (A * B) +/- 1
OR(A,B) = [(A +/- 1) * (B +/- 1)] +/- 1
NOR(A,B) = A +/- 1) * (B +/- 1)

There may be a way to simplify, and I'm wondering if there are other solutions to this problem. You could map 1s and 0s in many different ways (Even, Odd, Positive, Negative, Zero, Prime, Composite, etc.

It's probably mathematically insignificant, but it's still nifty.

 

I dunno how useful it is, probably not at all, but it's interesting never-the-less.

Anyways, here's a solution I've found!

If you consider all odd #'s as 1/HIGH/TRUE and all even #'s as 0/LOW/FALSE then all boolean functions can be performed via ordinary algebraic functions as follows:

NOT(A) = A +/- 1
XOR(A,B) = A +/- B
XNOR(A,B) = A +/- B +/- 1
AND(A,B) = A * B
NAND(A,B) = (A * B) +/- 1
OR(A,B) = [(A +/- 1) * (B +/- 1)] +/- 1
NOR(A,B) = A +/- 1) * (B +/- 1)

There may be a way to simplify, and I'm wondering if there are other solutions to this problem. You could map 1s and 0s in many different ways (Even, Odd, Positive, Negative, Zero, Prime, Composite, etc.

It's probably mathematically insignificant, but it's still nifty.

What you've basically discovered is a modulo-2 world.

By saying that things only depend on whether a value is even or odd (and note that, in doing so, you are also restricting yourself to integers) you are really saying that all you are interested in is the least significant bit of a value.

Note that you have NOT restricted yourself to only positive integers -- negative integers will work just fine.

In a mod-2 world,

A+1 = A-1

AA = A (even*even = even; odd*odd = odd)
A+A = 2A = 0 (2*anything is even)

NOT A = A+1
A AND B = AB

Since we have AND and NOT, we have a complete logic system.

A NAND B = NOT(A AND B) = AB + 1
A OR B = NOT( (NOT A) AND (NOT B) ) = (A+1)(B+1) + 1 = AB + A + B
A NOR B = (NOT A) AND (NOT B) = (A+1)(B+1) = AB + A + B + 1

A XOR B = [(NOT A) AND (B)] OR [(A) AND (NOT B)]
A XOR B = [(A+1)(B)] OR [(A)(B+1)]
A XOR B = (AB+B) OR (AB+A)
A XOR B = (AB+B+1)(AB+A+1) + 1
A XOR B = (AB+B+1)(AB+A+1) + 1
A XOR B = AB(AB+A+1)+B(AB+A+1)+(AB+A+1) + 1
A XOR B = ABAB+AAB+AB+ABB+AB+B+AB+A+1+1
A XOR B = (AB)(AB)+(AA)B+AB+A(BB)+AB+B+AB+A+(1+1)
A XOR B = AB+AB+AB+AB+AB+B+AB+A
A XOR B = (AB+AB)+(AB+AB)+(AB+AB)+(A+B)
A XOR B = A+B

 

Glad I read the thread through. Great (as always) explanation, WBahn.

First, WBahn has proven that in this case, the system and tautologies are functionally complete (from an old mathematician). It also appears consistent, but I am confused by a discussion that seems to imply that arithmetic may not be consistent (I am basing these comments on research on Wikipedia. I was looking for a description of the results of WBahn's explanation). I reiterate, my degree is several decades old, so I could be wrong and not know it.

However, I was about to state something similar. I use similar/logic when programming to map data to specific states to determine which processing rules (use cases) to apply.

Even when using the logical functions with loosely typed variables, one has to be careful. For example, many people use 1 to represent True. But NOT 1 may be -2 or 254, depending on the language, processor, and/or maybe compiler. These may be interpreted as true when indeed the operation should return false.

If Boolean constants are not available, I tend to define my own constants, with True=-1 and False=0. But this is not universal. I will write a test program to check out how a given combination of language, processor and compiler /interpreter/ run time module treats logical values and operations. One has to be consistent. You can learn how to program such that these differences have minimal impact in different environments.

Finally, since your example showed a floating point operation, it's clear that you're referring to programming. Programmers tend to use multiple flags to determine execution. I prefer to use the case structure with one state variable. Hence, my earliest reference.

Sorry for my rambling, but I hope this is useful.

 

What you've basically discovered is a modulo-2 world.

By saying that things only depend on whether a value is even or odd (and note that, in doing so, you are also restricting yourself to integers) you are really saying that all you are interested in is the least significant bit of a value.

Note that you have NOT restricted yourself to only positive integers -- negative integers will work just fine.

In a mod-2 world,

A+1 = A-1

AA = A (even*even = even; odd*odd = odd)
A+A = 2A = 0 (2*anything is even)

NOT A = A+1
A AND B = AB

Since we have AND and NOT, we have a complete logic system.

Ah, yes, the mod-2 perspective makes a lot of sense. that's a great way to help rationalize this.

I always thought it'd be neat to study/learn boolean algebra in context with the "traditional" realm of mathematics.

 

Glad I read the thread through. Great (as always) explanation, WBahn.

First, WBahn has proven that in this case, the system and tautologies are functionally complete (from an old mathematician). It also appears consistent, but I am confused by a discussion that seems to imply that arithmetic may not be consistent (I am basing these comments on research on Wikipedia. I was looking for a description of the results of WBahn's explanation). I reiterate, my degree is several decades old, so I could be wrong and not know it.

However, I was about to state something similar. I use similar/logic when programming to map data to specific states to determine which processing rules (use cases) to apply.

Even when using the logical functions with loosely typed variables, one has to be careful. For example, many people use 1 to represent True. But NOT 1 may be -2 or 254, depending on the language, processor, and/or maybe compiler. These may be interpreted as true when indeed the operation should return false.

If Boolean constants are not available, I tend to define my own constants, with True=-1 and False=0. But this is not universal. I will write a test program to check out how a given combination of language, processor and compiler /interpreter/ run time module treats logical values and operations. One has to be consistent. You can learn how to program such that these differences have minimal impact in different environments.

Finally, since your example showed a floating point operation, it's clear that you're referring to programming. Programmers tend to use multiple flags to determine execution. I prefer to use the case structure with one state variable. Hence, my earliest reference.

Sorry for my rambling, but I hope this is useful.

One way to define Boolean constants even when you don't know what values are True and False is to do something like this (using C syntax).

TRUE = (1 == 1);
FALSE = !TRUE

Back when I was first learning C I didn't know that the language standard (didn't even know about such things as language standards) specified the values of True and False and I thought that each compiler could define its own, so I always had at the top of my code

#define TRUE (1 == 1)
#define FALSE (!TRUE)

Even after I learned more I still defined these constants to make my code more readable.

#define FALSE (0)
#define TRUE (!FALSE)

I do it this way for no particularly good reason since True is defined to be 1 (when the result of any logical expression).

One point you made is particularly important, namely that multiple values can represent the same Boolean value. In C (and most languages that I work with these days) it is basically the opposite of what you describe -- a 0 is a Boolean False and anything other than 0 (exactly zero) is a Boolean True. This can cause problems for people that don't keep this in mind. For instance, when working with functions from the ctype.h library, functions like isdigit() don't return a 1 if True, they simply return something other that zero and the exact value depends on the data passed to them. The reason is that this allows the functions to be simpler and use simple masking operations to identify whether a particular code falls in a particular category. But it makes it so that doing something like

if (isdigit(a) == isdigit(b))
printf("a and b are either both digits or both nondigits")

doesn't work as expected. But a minor tweak will take care of it

if ( (!isdigit(a)) == (!isdigit(b)) )
printf("a and b are either both digits or both nondigits")



Of course, this requires that a logical expression produce a result that can be assigned to a variable
that will work in any language that supports logical operations is to do something like this: