I reached the end of a pretty long Boolean simplification, where I was supposed to prove that something = a. I reached a point (a and (not b)) or (a and b). Any further reorganization of the equation did not bring me further. But using a Truth tabel I checked to see that (a and (not b)) or (a and b) indeed does equal a. And it does make sense intuitively too, but can you actually use the Laws of Boolean Algebra to turn (a and (not b)) or (a and b) into a?
-
If a is true, what is the result for the different values of b? If a is false, what is the result for the different values of b? – TZHX Nov 15 '17 at 23:12
-
1I'm voting to close this question as off-topic because it is about boolean algebra and [math.se] instead of programming or software development. – Pang Nov 17 '17 at 01:48
-
2*(It is raining and it is not nighttime) or (it is raining and it is nighttime) = (it is raining)* – ImaginaryHuman072889 Nov 17 '17 at 11:46
4 Answers
It makes more sense when you use the simplified notation, * for and, + for or, ~ for not.
(a and b) or (a and (not b)) =
(a*b)+(a*(~b)) =
a*(b+(~b)) =
a*(1) =
a

- 64
- 3
((a and (not b)) or (a and b)) ... distributive law
<=> (a and (b or not b) ... (b or not b) is alway true
<=> a

- 36
- 3
-
Shouldn't [(a and (not b)) or (a and b)] | distributive law <=> [(a or a) and (a or b) and ((not b) or a) and (not b or b)] <=> [a and (a or b) and ((not b) or a)] ? – serialExperiments Nov 15 '17 at 23:26
Feel free to distribute:
c = (a and ¬b)
(a and b) or c
(a or c) and (b or c)
(a or (a and ¬b)) and (b or (a and ¬b))
distribute again for both the left and right sides:
((a or a) and (a or ¬b)) and ((b or a) and (b or ¬b))
simplify:
(a and (a or ¬b)) and ((b or a) and T)
(a and (a or ¬b)) and (b or a)
simplify again (using the absorption property = x and (x or y) == x):
(a) and (b or a)
and again:
a and (a or b)
== a
(I know this is a bit of the long way around...)

- 8,200
- 2
- 17
- 39
First about a AND NOT-b
:
-- if both a
and b
are already in the form of 1-bit booolean flags
0/1
, and the flags are data types that allow for straight up numeric comparisons without extra re-casting,
instead of doing,
a && ! b
I think of it as simply :
b < a
i.e. b strictly less than a
necessitating a
being the larger one makes it the bottleneck, since any TRUE (1)
in b
instantly fails the criteria, as does a
's own FALSE (0)
scenario.
put it another way -
"if either I (a) have nothing, or you (b) have something, then we've failed"
so the flip side of that coin becomes
"I (a) must have something when you (b) have nothing for us to succeed"
now the 2nd half of it, a AND b
a && b
think of it like multiplication of boolean flags
a x b
the 2 verbose ways of saying it would be
"if either us have nothing, then we've failed"
flipping that over ……
"I (a) must have something when you (b) also have something for us to succeed"
And finally, the either OR
, simply concat those sentences as
"EITHER
I (a) must have something when you (b) have nothing,
OR
I (a) must have something when you (b) also have something,
in order for us to succeed"
That paragraph in boolean algebra would be like
(a == True, b == False) or ( a == True, b == True )
i.e. it doesn't matter what b
has at all, since both scenarios are covered, so the outcome would simply be whatever a
has.

- 2,453
- 3
- 11