You show me the code and I will give you a FSM that is the same thing.
You are talking about implementing this in logic... a FSM.
The only way it is *not* a FSM is if it is a trivially simple one with no state information, just logic. But even that is a degenerate version of a FSM.
So what about this isn't a FSM? Something has to remember what state... opps - *room* you are/were in and depending on the inputs... opps - calls that come in you take an action which may or may not also alter your state...
No. A state machine has state VARIABLES -- *storage*. Where is the *storage*?
No. "Logic" is not the same as a state machine. Logic has no memory. There is no sense of "sequence" (which implies memory) in the "logic rules".
No.
If A and B then C
is a simple conditional -- an AND gate. There is no storage implied.
If "A" happens to be the output of a comparator that checks a voltage against a reference, there is still no "stored state".
If (mode==cooling) and (temperature > setpoint) then turn_on_ACbrrr If (mode==heating) and (temperature < setpoint) then turn_on_furnace
Again, NO STATE! Just combinational logic that examines the input signals and drives an output signal accordingly.
There's no "state register" in the LOGIC that I described!
A person's location is a dynamic input -- just like a temperature to a thermostat. When it changes, then different rules are potentially enabled (if their predicates rely on the location being that which it currently is).
If the first iteration of the inference engine is told the user is in the kitchen, then any rules for which "LOCATION==KITCHEN" are potentially enabled including, for example, a rule that says "if (LOCATION == INDOORS) -- because another rule defines "INDOORS" to be "KITCHEN or BEDROOM or LIVING_ROOM or..." FOR *THIS* ITERATION OF THE INFERENCE ENGINE -- it's not "memory".
Do you want to call the *person* a state variable? Do you want to call the current indoor temperature a state variable? What about the technician holding a jumper wire to the input of the AND gate shorting it to GND?
A state machine examines some notion of "current state" (some number of some-valued -- potentially non-binary -- state variables) and drives outputs based on current inputs AND UPDATES STATE VARIABLES AS NECESSARY (as if another set of outputs)
[ignoring the duality of Mealy-Moore]
There is no state stored in the productions I illustrated above. Their values change each time the inputs change (and the inference engine runs). They might react to the "state of the world" but they don't store/embody state.
As I said, that is only an issue with the current implementation of this particular type of location tracking system. Give me fine grained GPS/WAAS that works *inside* my home and there's
*no* memory required. It's an implementation hack to allow a cheaper technology to be used to RELIABLY provide a "location".
Just like a cap can be used to debounce a switch (because you don't want to pay for EXPENSIVE switches that provide IDEAL inputs to your circuit -- completely free of "transition effects" like bounce!)
You can play your mind games, but you have acknowledged that the system you described has *memory*. Even the present location will have to be "remembered" because you may not presently be tripping any given detector. Will the system assume you have teleported to another location where it can't see you? No, it "remembers" the last location it has for you until it sees you leave.
Regardless, you are picking nits. There is virtually no difference in the way you code this stuff. It is just a huge matrix of possible inputs and the outputs you desire. Same with random logic or a FSM.
BTW, GPS would have a lot of difficulty distinguishing the room you are in. It is just not that reliably accurate even with WAAS which is somewhat overrated. My GPS... when it worked, RIP... did just as well indoors as out, around 15 foot accuracy some 80% of the time. I had a program that would draw a trace of where it thought it was and it wandered all around reaching over 50 foot from the center location over a few hours. The system would think I had gone to the garage and gotten in my car to drive off, then rapidly came flying back through the picture window into the living room!
Don't count on GPS to track you in your house any time soon.
Every computer has memory. The production system -- the rules and inference engine -- do not rely on memory to implement what I have described.
E.g., if the house had pressure plates in the floor that operated contact closures, then "location" would just be a logical OR of all the plates in the KITCHEN, vs, all the plates in the LIVING_ROOM, etc. And NONE OF THE PRODUCTIONS (rules) WILL CHANGE WHEN YOU MAKE THAT CHANGE TO THAT SUBSYSTEM.
My current system uses RF beacons. The reason it uses memory is because other people may be present in the residence wchich can introduce dynamic shadows, etc.
E.g., the pressure plate solution (assuming no other people in the residence) needs no "memory" to keep track of where I am located.
[If you refuse to accept this, then imagine someone walks around behind me constantly typing my location -- as he observes -- into the system. Where is the SYSTEM STATE VARIABLE, now?]
No, there is a huge difference! You can't implement sequences without state. So, combinational logic can't "count". The production system has no way of encoding a rule like: if PREVIOUS_LOCATION==KITCHEN and LOCATION==DINING_ROOM then TURN_OFF_KITCHEN_LIGHT. because there is no *memory* in the production system.
Instead, it has to implement this as: if LOCATION != KITCHEN then TURN_OFF_KITCHEN_LIGHT
OTOH, a purely combinational approach eliminates lots of other variables that can get "set" from the environment/observations which must then be accommodated in the logic.
Adding memory means you now need to worry about what is "remenbered" -- as each of these are still potential inputs to the rule system.
E.g., the subsystem that deduces likely *activities* relies on history -- because many things can't be derived from a direct observation of CURRENT conditions. So, when that system wants to do something like determine if I am asleep, it has to have rules like:
if ENTERED_BEDROOM then START_TIMER; if LOCATION==BEDROOM and LAST_LOCATION!=BEDROOM then ENTERED_BEDROOM; if LOCATION==BEDROOM and TIMER>15minutes then SLEEPING; if LOCATION!=BEDROOM and LAST_LOCATION==BEDROOM then CLEAR_TIMER; etc.
I.e., otherwise, a started timer can easily attain 15minutes even if I leave the bedroom and return 2 hours later.
(Or, worse, if the SHOWERING activity sees me in the BATHROOM and WATER_RUNNING -- even momentarily -- causes the *same* timer to be examined for a value of >2minutes)
That's why FSMs are so much harder to implement at this scale. You have to account for every possible way you can get to "here" instead of just looking at "here" (inputs).
I offered it as an example of how you can get LOCATION without "memory" (of previous location). You can use video imagery to directly resolve location (assume 100% coverage). Or, Ir/RF beacons. Or, transition detectors (e.g., entering doorways) with some sense of state MAINTAINED IN THE LOCALIZER. Or, ultrasonic range detectors. Or...
Regardless of the technology used to determine location (or activity or whatever), the rules governing how the system reacts to your *commands* doesn't need to be changed. Because it doesn't care about HOW you figure out where the user is located -- even if you *ask* the user where he is each time he asks you to perform an action (hide that question IN the localizer so the "system" never has to deal with uttering it).
In practice, systems rely on memory to *filter* and/or *cache* data. All enhance performance in some manner -- either to bring it up to "adequate" or to make it "excellent". A simple bang-bang thermostat uses memory to implement hysteresis -- to enhance the control (so the furnace doesn't stutter on and off each time someone walks past the thermostat)
You don't have to trust me on this. You can try to code a similar sort of system -- even a trivial one -- as an FSM. You will *quickly* find cases where you forgot to "forget" something (or, alternatively, to *remember* something!) and the system is behaving in unexpected ways. If you've ever thought of how hard it is to analyze every path through a piece of conditional logic, imagine what it is like with *thousands* of rules!
[There have been some interesting cases of "learning systems" where the "learned facts" were surprising to the knowledge engineers who designed the system -- simply because they had never thought along those lines!]
*You* injected yourself into this conversation -- with an incorrect statement:
"He can call it what he wants, it is still a FSM."
I've spent a fair bit of time illustrating why it is not, need not be and SHOULD not be implemented as an FSM.
Now, you seem to be suffering sour grapes at having that pointed out to you...
Feh.
I should learn to pose problems WITHOUT context -- as if "homework assignments" -- so folks who can't deal with abstractions aren't drawn into the conversation and then complain that it has "[gone] far afield" ("Why do you want to do that?" "Oh, just because...").
No sour grapes, you have acknowledged you need state. Even the parts you don't acknowledge still need state. For any good "secretary" to do the job more is needed than just "where are we?" It is important to know the path that brought us here.
An example in your own terms... user walks from living room to kitchen around dinner time implies they are preparing dinner. User walks to kitchen from the garage and returns to garage and back to the kitchen implies returning from a trip to the store and putting away groceries.
I would not mind receiving a phone call from most people when I'm putting away groceries, but I don't want to be interrupted while cooking dinner or even making a bowl of popcorn or it might burn.
So the system needs to know more than just the present inputs. It needs state.
See how short and to the point that was? Your post would have been ten times as long.
You've missed the point. If you try to drag history into the decision, the problem quickly grows beyond a manageable (debuggable) size.
How do you handle:
"User has been reading the paper at the kitchen table for the past two hours. 5:00 comes along and he STAYS IN THE KITCHEN and starts to prepare dinner."
How do you decide that he's now making dinner? All that has changed is the *time*!
Or:
"User comes into kitchen (which adjoins garage, here) from garage to WASH THE GREASE OFF HIS HANDS from changing the oil in the car."
How do you decide that this is different from "unloading the groceries"?
I wouldn't want to deal with the phone while my hands were covered in grease! (see above) But, might want to if I'm just sitting reading the paper (because it's not dinner time).
No. There are too many "conditions" to address -- every state variable adds "inputs".
Your thermostat has no idea if it is humid outdoors or not. It deals with HEAT vs. COOL and little more. Yet, you would ideally like to set the indoor conditions differently if it is humid (e.g., raining!) outside. And, even more differently if you have been working outdoors (and want to cool off/dry off quickly).
The point of this (trivial) example is to show that it is easy to grow a problem beyond a point that any solution is possible!
I've carefully considered "usage", here. I can't, for example, reliably detect if you are washing your hands (in the bathroom), taking a piss, taking a dump, showering, putting away linens, cleaning the sink/toilet, replacing a stop under the sink, painting the walls, vacuuming/washing the floor, running CAT5, retiling the shower stall, driving the porcelain bus, fallen on the floor, etc.
Instead, you reduce the complexity of the problem to something that is more manageable. *And*, provide facilities to allow the user to "correct" or "override" the system's choices.
E.g., if I'm shaving, "RADIO" could bring me the morning news (because I am in the bathroom). The same observable conditions (location, duration, whether or not water is running, etc.) can apply if I am "cleaning the sink". If I ask for "RADIO" and get the news (but, I would rather listen to some jazz), then I can *correct* it's choice. Or, know that the system will default to giving me "news" and, instead, explicitly
*ask* for JAZZ instead of just RADIO.
Consider how you would resolve each of the above potential (not imaginary!) "bathroom situations". What sorts of inputs would you need? How reliable would your conclusion(s) be? How well would a user be able to understand *why* the system was interpreting his/her commands in a particular manner?
Contrast that with: I'm in the bathroom. It's morning. The water is running at a gentle rate (for more than a "toilet flush"). RADIO should mean "news". If, instead, the water is running at a pretty good rate, chances are I'm taking a shower and would rather be listening to music (because I can't hear the spoken words of a newscast over the white noise of the shower; but, can make out the melody of a song that is playing "under" it)
As I would have pointed out the shortcomings in your assessment!
I've thought about this for a LONG time! Not just "what can be done" and "how it can be done" but, also, "how users will cope with it". I.e., a high percentage of users COMPLAIN about the complexity of the products that they own. If a user can "relate" to how the device is operating, then he can be more comfortable (principle of least surprise).
"Where" and "when" are easily related to our activities (in our own minds). "How I got to WHERE I am at this TIME" is far less obvious.
"Why are you bothering me to answer the phone?" "Because I thought you were unloading groceries" "Why is that?" "Because you came into the kitchen from the garage" "But I was changing the oil in the car! It was time!" "Oh. Sorry. Would you prefer I ask them to leave a message?"
That is MY point that this whole problem is intractable. A computer will never have sufficient info to understand what is going on. Duh! Heck half the time people don't know what is going on.
Obviously you need a "reading the paper" sensor, or maybe a "hands covered in grease" sensor.
Again, way too long of a post to deal with a simple concept.
No, it isn't! Just like controlling the indoor temperature is "doable" -- even if not *ideally* solved!
A hot and sweaty user (who just came inside from working outdoors) doesn't *expect* the thermostat to have anticipated that he would be hot and sweaty and, IDEALLY, like the temperature a bit lower (or, at least, the FAN running to move air to help evaporatively cool the perspiring user). He understands why it is *still* set at 78F and knows that he will have to manually take action to benefit from any additional cooling/comfort.
OTOH, he WON'T have to take action to ensure the house temperature is lowered at bedtime -- to save energy and/or provide for a cooler, more comfortable, sleeping environment.
Would you prefer a traditional, manual (mercury bulb on a thermostatic spring) thermometer that does exactly -- and ONLY -- what you set it to do? "Because the ENTIRE problem is intractable"?
And the user would have to be aware of all of these subtle differences in "his condition" -- because the system *would* (even if he didn't!)
Because you're still missing the point.
(sigh) I'll give you the final word. Your comments aren't pertinent to the subject of the post and I've got to get in a nap in order to be out of here by 6.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.