Unassailable dichotomies?

@sprinkles

Code: 
if current_level > previous_level:
   state = true;
else if current_level < previous_level:
   state = false;

This is my take on the switch. Compare the current level to the previous level. If it is raising, set the state to true. if it is sinking set the state to false.

I see what you're getting at, but I still think we're addressing different things here.

(current_level > previous_level) → (state)

This does not imply:

¬(current_level > previous_level) → ¬(state)

but (state) will still imply ¬(state)

On another note:

¬(state) will imply ¬(current_level > previous_level)
 
Also, on another side note;

(current_level > previous_level), and (current_level < previous_level) are both Boolean expressions that are either true or false. They are not in dichotomy to one another, but to ¬(current_level > previous_level) and ¬(current_level < previous_level) respectively.
 
Elis said:
@sprinkles

Code: 
if current_level > previous_level:
   state = true;
else if current_level < previous_level:
   state = false;

This is my take on the switch. Compare the current level to the previous level. If it is raising, set the state to true. if it is sinking set the state to false.

I see what you're getting at, but I still think we're addressing different things here.

(current_level > previous_level) → (state)

This does not imply:

¬(current_level > previous_level) → ¬(state)

but (state) will still imply ¬(state)

On another note:

¬(state) will imply ¬(current_level > previous_level)
Click to expand...

That's no what we want though. Based on that logic the pump would turn on immediately when it detected a change, and then turn off as soon as it detected another change. It needs a gap of some kind in order to not flip-flop.

¬(state) should not necessarily imply ¬(current_level > previous_level) because if the barrel fills up only half way and water stops coming in, you end up with ¬(state) and also (current_level > previous_level). Moreover, if water stops coming into the barrel for so long that water begins to evaporate, you can have a situation where ¬(current_level > previous_level) should actually not warrant a state change.

This is why float switches are best done with analog machinery.
 
sprinkles said:
That's no what we want though
Click to expand...

Ok, I think I didn't read the your description properly.

Is it supposed to turn on when you reach a max level and turn off when you reach a minimum level?

If so you can simply do

Code: 
if(current_level >= max_level):
   state := true
if(current_level <= minimum_level):
   state := false
 
Elis said:
Ok, I think I didn't read the your description properly.

Is it supposed to turn on when you reach a max level and turn off when you reach a minimum level?

If so you can simply do

Code: 
if(current_level >= max_level):
   state := true
if(current_level <= minimum_level):
   state := false
Click to expand...

That works, though it requires constant observation/reiteration and there's a hidden area where "current_level" evokes neither true nor false - when it is less than maximum but more than minimum. This doesn't matter to the program because it doesn't need to do anything with in between values, but the values are there, it's just tossing them out by design. However it is still relevant because we're spending cycles to check it, and to keep track of the variable. It will spend a lot of time in limbo evaluating neither statement as true, but it has to in order to ever know when it should finally do something.
 
[MENTION=6917]sprinkles[/MENTION]

I'd say that comes down to how it is implemented. I'm not arguing that I have a better solution than a float switch, frankly I don't even know how they work in detail. I was just referring to how you can solve practical things with Boolean logic.

Also, I thought you were addressing the state in dichotomy to ¬(state) but I guess that isn't the case.

cheers
 
Elis said:
[MENTION=6917]sprinkles[/MENTION]

I'd say that comes down to how it is implemented. I'm not arguing that I have a better solution than a float switch, frankly I don't even know how they work in detail. I was just referring to how you can solve practical things with Boolean logic.

Also, I thought you were addressing the state in dichotomy to ¬(state) but I guess that isn't the case.

cheers
Click to expand...

I was addressing that. It's still not a dichotomy, we're just able to get away with making the program ignore that fact and have it still work. The in between value is real enough that you have to power an oscilator (CPU) to keep track of it in order for this to work.

In the analog version you just have something like a little box that can float attached to a tether, and there's a little ball inside the box which can push on a switch inside the box. The tether is attached somewhere to the middle of the tank usually so that when the box floats, it tips end up and the ball rolls to one end of the box which allows a small arm to move and turn on the switch, and the arm is angled so it doesn't turn off the switch until the ball can roll completely to the other end when the tank is near empty and the box is pointing downwards.

Another way for smaller tanks is to just have a switch on the side with two prongs attached to it, spread out so one is near the top and one near the bottom and you have a guide wire between them which holds a weighted float that can move up and down the wire. It's buoyant enough that when it bumps the top prong it pushes it up and turns the switch on, and heavy enough that when it rests on the bottom prong it turns the switch off.
 
Again I think we are addressing different things.

The (state) in the program can be both true and false. Depending on language and implementation it can also be neither (not addressed any value). This was not what I meant when I said that (state) and ¬(state) are in dichotomy. Regardless, I still think it can be seen as a dichotomy. What I mean is that a variable that isn't assigned any value can be seen as an invalid variable, i.e. an invalid variable doesn't hold any valid values. A way to see it could be 'true', 'false' and 'unknown'. 'unknown' doesn't mean that the vault it represents is neither open nor closed, it simply means that the program doesn't know the state.

What I was trying to address with (state) and ¬(state) being a dichotomy was the actual state of the vault in reality.
 
Elis said:
Again I think we are addressing different things.

The (state) in the program can be both true and false. Depending on language and implementation it can also be neither (not addressed any value). This was not what I meant when I said that (state) and ¬(state) are in dichotomy. Regardless, I still think it can be seen as a dichotomy. What I mean is that a variable that isn't assigned any value can be seen as an invalid variable, i.e. an invalid variable doesn't hold any valid values. A way to see it could be 'true', 'false' and 'unknown'. 'unknown' doesn't mean that the vault it represents is neither open nor closed, it simply means that the program doesn't know the state.

What I was trying to address with (state) and ¬(state) being a dichotomy was the actual state of the vault in reality.
Click to expand...

Let's look at it this way.

This is a dichotomy:
wswmmf.png


This is not:
14l272c.png



If you choose to focus only on certain end points and ignore information then they both appear to be a dichotomy, but only one of them actually is. Even though a gradient is black and white on both ends, it's not a dichotomy due to the blending in the middle.

Similarly you can have two states that appear to be a dichotomy, such as true and false, but if an unknown is possible then it is not a dichotomy anymore similar to the gradient picture - there's black and white in the picture but it is not exactly divided between ONLY black and white.
 
@sprinkles

unknown isn't a real possibility of a state though. It is either true or false, to say that we don't know doesn't address the state. It was just a way to illustrate how we could interpret a Boolean without value. Still, it wasn't my point. My point was regarding what it represents in reality.

Also, as for your spectrum - you can construct an expression such as 'contains light' and do the same thing. (I know that that doesn't make the spectrum itself an dichotomy, but the constructed expression)

But really I am probably just outside of the definition so I don't think there is much to argue.
 
Elis said:
[MENTION=6917]sprinkles[/MENTION]

unknown isn't a real possibility of a state though. It is either true or false, to say that we don't know doesn't address the state. It was just a way to illustrate how we could interpret a Boolean without value. Still, it wasn't my point. My point was regarding what it represents in reality.

Also, as for your spectrum - you can construct an expression such as 'contains light' and do the same thing.

But really I am probably just outside of the definition so I don't think there is much to argue.
Click to expand...

Unknown is a state, I see your point though.

Going back to the float switch example, if you make a computerized version like you came up with the "current_value" variable is a quantization of an analog gradient (the water level) so for example it could be anywhere between 0 and 100, including fractions. Because you're tracking this number and including it in your two state evaluations, your two state evaluations become many-valued. Even though it comes down to true or false you have many ways of getting either answer, and we can't say the middle is unknown because we're tracking it.

On the other hand if you're tracking a coin flip then you have a dichotomy, and if you simply don't know the value of the flip then the unknown value doesn't remove the dichotomy because the coin is presumably still heads or tails even if you aren't aware. However it is the binary state of the data that forces the dichotomy, not the truth of it or your awareness.
 
sprinkles said:
Even though it comes down to true or false you have many ways of getting either answer, and we can't say the middle is unknown because we're tracking it.
Click to expand...
If we're in the middle of the spectrum we might check the current_level depending on how we implement it. This doesn't mean we're tracking the state at that point. state can only be altered at (and over) max point as well as at (or under) minimum point.

(current_level >= max_level) isn't logically equivalent with (state).

Instead of tossing a coin, we have a vault that is either opened or not. If we're not at max or min point when that part of the program is executed, the program simply doesn't know and don't alter it.
 
Elis said:
If we're in the middle of the spectrum we might check the current_level depending on how we implement it. This doesn't mean we're tracking the state at that point. state can only be altered at (and over) max point as well as at (or under) minimum point.

(current_level >= max_level) isn't logically equivalent with (state).

Instead of tossing a coin, we have a vault that is either opened or not. If we're not at max or min point when that part of the program is executed, the program simply doesn't know and don't alter it.
Click to expand...

The program does know. It knows to NOT alter the state.

Edit:
Moreover it knows exactly when to not alter the state because the variable does not match the requirements. It's not oblivious, it's checking repeatedly many times per second. It's implied by design that if the variable does not match the required condition, it does nothing.
 
Last edited:
[MENTION=6917]sprinkles[/MENTION]
Not to alter the state, but not the state.
 
Elis said:
[MENTION=6917]sprinkles[/MENTION]
Not to alter the state, but not the state.
Click to expand...

It better know the state because we don't want the pump to be running while the program says it is off.

Or better yet we don't want the program to ever be unsure about whether the pump should be on or off. If it's off it has to know it is off and vice versa. Especially if it's connected to machinery. You don't want to try and start a running motor repeatedly for example.
 
[MENTION=6917]sprinkles[/MENTION]

You could throw in a check when the program starts, to set the Boolean 'state' to its state. It will not need to check the value in the middle of the spectrum. as it will already be in its correct state.

You could argue that it already indirectly knows the state by looking at either last max/min or the initial state*, but even then there shouldn't be any problem as we then have an initial check to rule out the undefined state.

*I don't really see how that would be relevant though, as it does nothing with that "information".
 
Elis said:
You could throw in a check when the program starts, to set the Boolean 'state' to its state. It will not need to check the value in the middle of the spectrum. as it will already be in its correct state.

You could argue that it already indirectly knows the state by looking at either last max/min or the initial state*, but even then there shouldn't be any problem as we then have an initial check to rule out the undefined state.

*I don't really see how that would be relevant though, as it does nothing with that "information".
Click to expand...

It needs to make value checks at all times regardless of where the value is because the value is unpredictable. It's not "checking the middle" it is checking uncertain variable "current_level" on a scheduled clock cycle. WHEN it checks "current_level" on any given iteration the value may or may not end up being in the middle. If it IS in the middle on a given iteration, no state change is made. It does nothing with the information, but it's doing nothing on purpose.
 
Yes, that is one way to go about it. When I said it didn't have to check the value in the middle of the spectrum I meant the Boolean state, not current_level. My bad.

Either way, what are we arguing again ;)
 
Elis said:
Yes, that is one way to go about it. When I said it didn't have to check the value in the middle of the spectrum I meant the Boolean state, not current_level. My bad.

Either way, what are we arguing again ;)
Click to expand...

You might want it to check the state for failsafes or debugging purposes. This would actually be an area where a computer is superior because it can check the state where if an analog float switch gets a stuck contact, the pump is going to run dry until somebody notices and shuts it off. So with a program monitoring it you could periodically check what the state should be and correct it if it ends up being different from what the state actually is.

We're arguing why this isn't really a dichotomy.
 
alright, so. The vault being open or not is that a dichotomy? not the variable.
 
You must log in or register to reply here.
Back
Top