The transition from !signed_out? to signed_in? is entirely non-logical, so it's hard to see what it's doing in this post, which is supposedly illustrating logical laws (two of the most elementary logical laws, at that, that I'm surprised it would ever have occurred to someone to think needed introduction to an audience of professional programmers).
Not not x is equivalent to x using the double negation rule (DN).
"Not signed out" can be rephrased as "not not signed in" and thus simplified to "signed in". Same for "not untrusted ip" equaling "not not trusted ip" and, after DN, simply "trusted ip".
It's completely logical, so I'm not sure what your point is. Perhaps the article should have explained this better.
The fact that "signed out" and "signed in" are opposites is not a logical fact; there's no general inference from "not p_out" to "p_in".
If you had "outside" and went from !outside?" to "inside?", that would be erroneous (you could also be on the threshold).
ETA: this is especially obvious for trusted/untrusted; it doesn't have to be the case that every ip is either positively trusted or positively untrusted. If, in some application, it is binary in that way, then you can, in that case, go from not untrusted to trusted. But that isn't justified by purely logical considerations.
ETA again, in fact a better example is this, it's not a logical fact that if you flip a coin and it comes up not-heads, it has come up tails. (Even ignoring improbably things like its landing on its side.) That's a conclusion that is justified by knowledge of the substantive domain of coins.
The article title was clearer conditionals using DeMorgan's Law - to that end, the article illustrated how to move to that step for cleaner code through first applying the law.
Yes, and the other thing I find baffling is that a trivial post talking about something that would be covered in the first part of any baby logic course---before you even get to quantifiers!---is currently ranked as high as it is.
Amazon.com is perhaps a better example. That site has multiple sign-in levels. It's not a binary state. I'm not sure what names they use, but I'll call them signed-in, signed-in-untrusted, and signed-out.
If you are fully signed-in, you can purchase something or make account changes. If you are signed-in-untrusted, you can put things in the cart associated with your account, but you can't purchase anything without typing a password. If you are signed out, you are fully dissociated from any account.
Note that you can refactor that single trinary property into two binary properties: signed-in/signed-out and trusted/untrusted. (Signed-out+trusted happens to be unused.)
Perhaps it's obvious, but it's true that every multi-state property (or set of properties) can be broken down into a set of binary properties like that, and the breakdown can be done in multiple ways. The resulting binary properties may not be have sensible names as they do in my example, but it can be done. In general, find all possible combinations of values for your set of many-state properties. Enumerate those combinations and write the numbers in binary. Each binary digit is a property in your new set of binary properties. There are multiple possible enumerations, so there are multiple possible mappings from a set of many-state properties to a set of binary properties.
For example, if you have a three-state property and a four-state property, then you'll a combination of 12 possible states. Number those 12 states. Write those numbers in binary. You'll need at least four binary digits. That means you'll have at minimum four binary properties. Those four properties can have 16 total states, so four of the states will be unused.
You can similarly decompose your properties into a set of three-state properties by writing your enumeration in base-three. I suppose you could also consider the current state of your program, with it's many multi-state properties (integers have lots of possible states, strings have even more), to be a single variable-base number that enumerates a state in the state-space of your program. If you consider the remaining input to your program to be part of your state, and the set of all possible outputs to be enumerated in a similar fashion, then the problem of programming is reduced to the building of a machine that maps numbers from one set to numbers in another. How hard can that be? So I'll need your project done by Monday.
