Is there any advantage to using De Morgan's la

Question

I use pycharm and a few times when using if statements I have seen the suggestion to change the statement using De Morgan laws, such as with the following if statement:

if new_odds > 10 and new_odds <= 30:

if not (not (new_odds > 10) or not (new_odds <= 20)):

For me it makes it less readable, so is there any advantage to using De Morgan's laws or is it strictly a personal choice?

Answer 1

Given the results below it would seem that the more complex/less readable expression is also the slowest. In any case readability is most of the time more valuable in python.

In [1]: new_odds = 0  
In [2]: %timeit if new_odds > 10 and new_odds <= 30: pass  
10000000 loops, best of 3: 24.3 ns per loop

In [3]: %timeit if not (not (new_odds > 10) or not (new_odds <= 20)): pass  
10000000 loops, best of 3: 48.6 ns per loop  

In [4]: %timeit if 10 < new_odds <= 30:pass  
10000000 loops, best of 3: 43.4 ns per loop  

In [5]: new_odds = 20  
In [6]: %timeit if new_odds > 10 and new_odds <= 30: pass  
10000000 loops, best of 3: 57.7 ns per loop  

In [7]: %timeit if not (not (new_odds > 10) or not (new_odds <= 20)): pass  
10000000 loops, best of 3: 102 ns per loop  

In [8]: %timeit if 10 < new_odds <= 30:pass  
10000000 loops, best of 3: 52.7 ns per loop

Answer 2

In some cases, it makes things more verbose and readable. However, in cases where you already have a bunch of nots sprinkled around, or where you're comparing things in a less-than-natural order, demorganing can reduce the number of nots or reverse the order of the unequal comparisons. For example:

if not foo() and not bar():
if not(foo() or bar()):

if new_score <= high_score and new_level <= high_level:
if not (new_score > high_score or new_level > high_level)

(The second one is debatable… but that's exactly what you'd expect from a question of readability and style.)

So, if it makes your code more readable, do it; otherwise, don't.

---

There are a handful of languages (logic, constraint-satisfaction, relational, etc.) where this is not true, because applying a not to a value isn't just flipping True and False but generating a converse, possibly much slower, or possibly even indeterminate, query.

But that isn't the case with Python, or most other "general-purpose" languages.

Answer 3

In Python it is almost always better to be clear than slightly faster (if that even would have been, which I doubt).

I prefer this even simpler statement:

if 10 < new_odds <= 30:

Answer 4

It can be useful sometimes for readability but it's the same thing at execution. For example with:

not(A AND B) === not(A) OR not(B)

if not a() and not b():
if not(a() or b()):

The execution will be the same with a() True or False.

For your example, the best solution remains to use the power of the Python syntax and write:

if 10 < new_odds <= 30:

This syntax is extremely useful for checking that a numeric value is in a particular range.

Answer 5

De Morgan's laws state that:

"not (A and B)" is the same as "(not A) or (not B)"

and also,

"not (A or B)" is the same as "(not A) and (not B)"

Which are used to transform logic between alternate forms. So while the transformation you've done conforms to De Morgan's laws, it has become more difficult to read. As others have suggested the much simpler 10 < new_odds <= 30 would be much more readable, however it is very important to understand that this is short for 10 < new_odds and new_odds <= 30 because, following from this you can do logic like:

10 < new_odds <= 30 != max_odds | default_condition

Which expands to:

10 < new_odds and new_odds <= 30 and 30 != max_odds and max_odds | default_condition

So with that syntactic sugar in mind, lets look at another example:

We will consider a contrived example in simple role-playing game where we look at a skill we will call "dutch courage". The premise of this attack is that you can a bonus if you are at max health, and either your armor or your attack rating is insufficient to attack an enemy. I need to know when this rule won't apply.

Writing this out we have 4 conditions:

A = health == max_health
B = armor > enemy.attack
C = attack > enemy.defense
no_bonus = not(A and not(B and C))

Using De Morgan's laws I can decompose this thus:

not(A and not(B and C))
not(A) or not(B and C)
not(A) or not(B) or not(C)
not(health == max_health) or not(armor > enemy.attack) or (attack > enemy.defense)

Well, now I can decompose this further...

health < max_meath or armor < enemy.attack < attack > enemy.defense

Here we assume the opposite of == max_health is < max_health otherwise its not the maximum.

Although contrived, this shows us that De Morgan's laws are a tool to enable us to rewrite logic. Whether this logic is improved or not is up to the programmer, but the intent is to be able produce simpler constructs, that are first more readable and secondly and hopefully require less instructions and are thus faster.