Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
On 2014-09-15, David Harmon <source@netcom.com> wrote:
On Sat, 13 Sep 2014 11:57:59 -0700 in sci.electronics.design, Don Y
this@isnotme.com> wrote,
I'm looking for ideas on how to provide (reasonable) authentication
over the PSTN. CID is too readily spoofed (usually by the very folks
that you want to "avoid"!).
Use ANI.
hmm, you can get ANI by being a telco, or having a toll or toll-free
number.
On Sun, 14 Sep 2014 16:43:48 -0700, Don Y <this@isnotme.com> wrote:
E.g., if you are "in the conference room", chances are, you
won't want to take a call from a friend/acquaintance/sales rep.
If you're in "the corner office" -- along with several other
executives -- an incoming call from your SO should probably have
a higher threshold set for interruption: "Should I interrupt
his meeting with the execs?" ("No, just tell him I called and
ask him to please get back to me when he can")
The problem is that you're building a state machine with an unknown
number of states. You can do that successfully, but only to the point
where you go insane trying to define all possible states for all
possible input conditions. There are AI (artificial intelligence)
programs that will do that. I've scribbled one program each in Prolog
and LISP to see what they were like. More successfully, I worked on a
telephone answering contrivance, that used a state machine to
determine the outcome of all possible input conditions. The state
table was wall size. (The flow chart fit on letter size page). It's
not like you have only two possible states for your machine (i.e.
answer phone, don't answer phone). You also have a wide collection of
possible actions that can be performed for either state. What makes
this work is that with a state machine, everything happens at the same
time with storage for prior states. It can be done with a big lookup
table if necessary.
No. You don't treat it as an FSM. Instead, you recognize "likely
situations" (morning, bathroom, user1) and the likely actions that
will you will be called on to perform in each of those situations.
Ooch, such a silly thing to say that is.
More complex systems are not implemented as a single mega-state machine.
Even IEEE-488 bus (GPIB / HPIB) is implemented as a collection of
interacting simple state machines. Don't over complicate the design.
Factor out the separable state machines and define the interactions.
On Sun, 14 Sep 2014 16:43:48 -0700, Don Y <this@isnotme.com> wrote:
On 9/14/2014 2:40 PM, Jeff Liebermann wrote:
On Sun, 14 Sep 2014 13:28:36 -0700, Don Y<this@isnotme.com> wrote:
No. What I really want is an "electronic secretary".
It's been tried before:
http://www.rexophone.com/?p=1138
The "secretary" analogy/model is a good one, I feel. A "good"
secretary knows your habits, preferences, priorities, etc. and
can make decisions based on those.
It's much easier to have the electronic secretary run your life for
you than for it to guess what you're going to do next. For example,
the electronic secretary could prepare your schedule for you and
enforce compliance with the schedule through various unpleasant ways.
I vaguely recall a 1950's sci-fi story that revolved around that
theme.
It doesn't have to guess what you are going to do next. Rather,
know what the chances of your handling a particular situation
in a particular way are likely to be.
E.g., if your "routine" is to listen to the news in the morning
while rushing your teeth, then, chances are, if you command
the "RADIO" on in the morning while you are in the bathroom,
(i.e., no, you don't want the radio to be on in the living
room or kitchen -- because you aren't LOCATED in those places!)
it is LIKELY that you will want it tuned to the news station
(and not the Jazz station that you were listening to in bed the
night before).
If it errs, then the user is inconvenienced but not harmed.
(i.e., you now have to call for NEWS instead of just the
radio/TV)
E.g., if you are "in the conference room", chances are, you
won't want to take a call from a friend/acquaintance/sales rep.
If you're in "the corner office" -- along with several other
executives -- an incoming call from your SO should probably have
a higher threshold set for interruption: "Should I interrupt
his meeting with the execs?" ("No, just tell him I called and
ask him to please get back to me when he can")
The problem is that you're building a state machine with an unknown
number of states. You can do that successfully, but only to the point
where you go insane trying to define all possible states for all
possible input conditions. There are AI (artificial intelligence)
programs that will do that. I've scribbled one program each in Prolog
and LISP to see what they were like. More successfully, I worked on a
telephone answering contrivance, that used a state machine to
determine the outcome of all possible input conditions. The state
table was wall size. (The flow chart fit on letter size page). It's
not like you have only two possible states for your machine (i.e.
answer phone, don't answer phone). You also have a wide collection of
possible actions that can be performed for either state. What makes
this work is that with a state machine, everything happens at the same
time with storage for prior states. It can be done with a big lookup
table if necessary.
No. You don't treat it as an FSM. Instead, you recognize "likely
situations" (morning, bathroom, user1) and the likely actions that
will you will be called on to perform in each of those situations.
Ooch, such a silly thing to say that is.
More complex systems are not implemented as a single mega-state machine.
Even IEEE-488 bus (GPIB / HPIB) is implemented as a collection of
interacting simple state machines. Don't over complicate the design.
Factor out the separable state machines and define the interactions.
On 9/16/2014 2:17 AM, josephkk wrote:
On Sun, 14 Sep 2014 16:43:48 -0700, Don Y <this@isnotme.com> wrote:
On 9/14/2014 2:40 PM, Jeff Liebermann wrote:
On Sun, 14 Sep 2014 13:28:36 -0700, Don Y<this@isnotme.com> wrote:
No. What I really want is an "electronic secretary".
It's been tried before:
http://www.rexophone.com/?p=1138
The "secretary" analogy/model is a good one, I feel. A "good"
secretary knows your habits, preferences, priorities, etc. and
can make decisions based on those.
It's much easier to have the electronic secretary run your life for
you than for it to guess what you're going to do next. For example,
the electronic secretary could prepare your schedule for you and
enforce compliance with the schedule through various unpleasant ways.
I vaguely recall a 1950's sci-fi story that revolved around that
theme.
It doesn't have to guess what you are going to do next. Rather,
know what the chances of your handling a particular situation
in a particular way are likely to be.
E.g., if your "routine" is to listen to the news in the morning
while rushing your teeth, then, chances are, if you command
the "RADIO" on in the morning while you are in the bathroom,
(i.e., no, you don't want the radio to be on in the living
room or kitchen -- because you aren't LOCATED in those places!)
it is LIKELY that you will want it tuned to the news station
(and not the Jazz station that you were listening to in bed the
night before).
If it errs, then the user is inconvenienced but not harmed.
(i.e., you now have to call for NEWS instead of just the
radio/TV)
E.g., if you are "in the conference room", chances are, you
won't want to take a call from a friend/acquaintance/sales rep.
If you're in "the corner office" -- along with several other
executives -- an incoming call from your SO should probably have
a higher threshold set for interruption: "Should I interrupt
his meeting with the execs?" ("No, just tell him I called and
ask him to please get back to me when he can")
The problem is that you're building a state machine with an unknown
number of states. You can do that successfully, but only to the point
where you go insane trying to define all possible states for all
possible input conditions. There are AI (artificial intelligence)
programs that will do that. I've scribbled one program each in Prolog
and LISP to see what they were like. More successfully, I worked on a
telephone answering contrivance, that used a state machine to
determine the outcome of all possible input conditions. The state
table was wall size. (The flow chart fit on letter size page). It's
not like you have only two possible states for your machine (i.e.
answer phone, don't answer phone). You also have a wide collection of
possible actions that can be performed for either state. What makes
this work is that with a state machine, everything happens at the same
time with storage for prior states. It can be done with a big lookup
table if necessary.
No. You don't treat it as an FSM. Instead, you recognize "likely
situations" (morning, bathroom, user1) and the likely actions that
will you will be called on to perform in each of those situations.
Ooch, such a silly thing to say that is.
More complex systems are not implemented as a single mega-state machine.
Even IEEE-488 bus (GPIB / HPIB) is implemented as a collection of
interacting simple state machines. Don't over complicate the design.
Factor out the separable state machines and define the interactions.
He can call it what he wants, it is still a FSM.
E.g., if you are "in the conference room", chances are, you
won't want to take a call from a friend/acquaintance/sales rep.
If you're in "the corner office" -- along with several other
executives -- an incoming call from your SO should probably have
a higher threshold set for interruption: "Should I interrupt
his meeting with the execs?" ("No, just tell him I called and
ask him to please get back to me when he can")
On 9/16/2014 7:22 PM, Don Y wrote:
On 9/16/2014 3:26 PM, rickman wrote:
On 9/16/2014 2:17 AM, josephkk wrote:
On Sun, 14 Sep 2014 16:43:48 -0700, Don Y <this@isnotme.com> wrote:
No. You don't treat it as an FSM. Instead, you recognize "likely
situations" (morning, bathroom, user1) and the likely actions that
will you will be called on to perform in each of those situations.
Ooch, such a silly thing to say that is.
More complex systems are not implemented as a single mega-state
machine.
Even IEEE-488 bus (GPIB / HPIB) is implemented as a collection of
interacting simple state machines. Don't over complicate the design.
Factor out the separable state machines and define the interactions.
He can call it what he wants, it is still a FSM.
No, it isn't. If you approach it in that manner, you will fail,
miserably.
If it *is*, then identify the *states*.
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.
Rather, use a production system:
E.g., if you are "in the conference room", chances are, you
won't want to take a call from a friend/acquaintance/sales rep.
if LOCATION==CONFERENCE_ROOM and CALLER=={FRIEND|ACQUAINTANCE|REP}
then DON'T_TAKE_CALL
If you're in "the corner office" -- along with several other
executives -- an incoming call from your SO should probably have
a higher threshold set for interruption: "Should I interrupt
his meeting with the execs?" ("No, just tell him I called and
ask him to please get back to me when he can")
if LOCATION==CORNER_OFFICE and COUNT(CORNER_OFFICE, EXECUTIVES) >= 3
and CALLER==SO then ASK_IF_MEETING_SHOULD_BE_INTERRUPTED
similarly,
if LOCATION==BATHROOM then TAKE_A_MESSAGE
etc.
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... <in corner office and taking a call
Duh!
How much you choose to condition each rule is a matter of choice.
E.g., you could just as easily have:
if LOCATION==CORNER_OFFICE and COUNT(CORNER_OFFICE, EXECUTIVES) >= 3
and CALLER==SO then
if WORKING_HOURS then ASK_IF_MEETING_SHOULD_BE_INTERRUPTED
if AFTER_5 then TAKE_CALL
You have a sh*tload of rules (productions) but very little *state*!
What you might *consider* as "state" is really just an input to
a big combinatorial circuit.
So you *DO* know what a FSM is then!
Inputs +-------+ +-------+
----+------>| State | | State |
| | |--->| |---+
| +-->| Logic | | Reg | |
| | +-------+ +-------+ |
| +----------------------------+
| | +-------+
| +-->| Output|
| | |-------> Outputs
+------>| Logic |
+-------+
Yes, lots of logic...
Writing such systems "from scratch" is tedious and error prone.
OTOH, having an *agent* write them based on observataions of
your behavior hides much of the tedium *and* allows the rules
to change without requiring the user to sit down for a rewrite!
For example:
if USER==CEO and
if LOCATION==CORNER_OFFICE and COUNT(CORNER_OFFICE, EXECUTIVES) >= 3
and CALLER==SO then TAKE_CALL
Agents aren't inherently "safe" from creating conflicting rule
sets! OTOH, they can be coded to enforce invariants that protect
against this.
For example, if, based on observations, the system sees that
your response to a given set of INPUT CONDITIONS varies (perhaps
because of some other condition that it can not observe, directly),
it can offer you a *choice* as to how the situation is resolved
(i.e., it can *require* further clarification FROM YOU).
There are spots in the house where resolving my location can be
ambiguous -- "is he in the kitchen or the adjoining dining room?".
If the rules regarding how to interpret my current actions/commands
in those two locations *differ*, I have to resolve the ambiguity
"manually". This could be done by clarifying my position to the
system ("I am in the Dining Room"); *moving* so my position is
*less* ambiguous (though it can STILL be ambiguous -- as long as
the ambiguity doesn't cause my action to be interpreted in two
or more different ways); or more explicitly refine the command.
But, there's still no "state" involved -- just "current inputs"
examined, rules scanned, production(s) scheduled, conflict(s)
resolved and, eventually, action(s) taken.
I use state *in* subsystems -- primarily to cache results and
overcome inadequacies in the technologies. E.g., the location
resolution system doesn't make a decision based on "inputs"
tied to your current "location" but, rather, knows what it's
most recent decision was and, assuming it hasn't been told
otherwise, assumes that will be "near" your current location.
If your previous location was "kitchen" and your new location
APPEARS to be "master bedroom", it's simply not possible for
you to have made that change in location that quickly (given
this floorplan). So, it holds off claiming you are in the
master bedroom in the hope that new sensor data will explain
this "error" -- perhaps something has interfered with the
signal path, etc.
Previous location was remembered, so it is part of your state.
A "better" implementation that yielded correct data *solely*
from current inputs wouldn't need the "filtering" that my
state variable presents.
This is far too tedious to analyze everything you have written. I
usually don't even read most of it. Brevity is the soul of wit!
On 9/16/2014 6:39 PM, rickman wrote:
On 9/16/2014 7:22 PM, Don Y wrote:
On 9/16/2014 3:26 PM, rickman wrote:
On 9/16/2014 2:17 AM, josephkk wrote:
On Sun, 14 Sep 2014 16:43:48 -0700, Don Y <this@isnotme.com> wrote:
No. You don't treat it as an FSM. Instead, you recognize "likely
situations" (morning, bathroom, user1) and the likely actions that
will you will be called on to perform in each of those situations.
Ooch, such a silly thing to say that is.
More complex systems are not implemented as a single mega-state
machine.
Even IEEE-488 bus (GPIB / HPIB) is implemented as a collection of
interacting simple state machines. Don't over complicate the design.
Factor out the separable state machines and define the interactions.
He can call it what he wants, it is still a FSM.
No, it isn't. If you approach it in that manner, you will fail,
miserably.
If it *is*, then identify the *states*.
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.
No. A state machine has state VARIABLES -- *storage*. Where is
the *storage*?
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.
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".
Rather, use a production system:
E.g., if you are "in the conference room", chances are, you
won't want to take a call from a friend/acquaintance/sales rep.
if LOCATION==CONFERENCE_ROOM and CALLER=={FRIEND|ACQUAINTANCE|REP}
then DON'T_TAKE_CALL
If you're in "the corner office" -- along with several other
executives -- an incoming call from your SO should probably have
a higher threshold set for interruption: "Should I interrupt
his meeting with the execs?" ("No, just tell him I called and
ask him to please get back to me when he can")
if LOCATION==CORNER_OFFICE and COUNT(CORNER_OFFICE, EXECUTIVES) >= 3
and CALLER==SO then ASK_IF_MEETING_SHOULD_BE_INTERRUPTED
similarly,
if LOCATION==BATHROOM then TAKE_A_MESSAGE
etc.
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... <in corner office and taking a call
Duh!
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.
How much you choose to condition each rule is a matter of choice.
E.g., you could just as easily have:
if LOCATION==CORNER_OFFICE and COUNT(CORNER_OFFICE, EXECUTIVES) >= 3
and CALLER==SO then
if WORKING_HOURS then ASK_IF_MEETING_SHOULD_BE_INTERRUPTED
if AFTER_5 then TAKE_CALL
You have a sh*tload of rules (productions) but very little *state*!
What you might *consider* as "state" is really just an input to
a big combinatorial circuit.
So you *DO* know what a FSM is then!
Inputs +-------+ +-------+
----+------>| State | | State |
| | |--->| |---+
| +-->| Logic | | Reg | |
| | +-------+ +-------+ |
| +----------------------------+
| | +-------+
| +-->| Output|
| | |-------> Outputs
+------>| Logic |
+-------+
Yes, lots of logic...
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.
Writing such systems "from scratch" is tedious and error prone.
OTOH, having an *agent* write them based on observataions of
your behavior hides much of the tedium *and* allows the rules
to change without requiring the user to sit down for a rewrite!
For example:
if USER==CEO and
if LOCATION==CORNER_OFFICE and COUNT(CORNER_OFFICE, EXECUTIVES) >= 3
and CALLER==SO then TAKE_CALL
Agents aren't inherently "safe" from creating conflicting rule
sets! OTOH, they can be coded to enforce invariants that protect
against this.
For example, if, based on observations, the system sees that
your response to a given set of INPUT CONDITIONS varies (perhaps
because of some other condition that it can not observe, directly),
it can offer you a *choice* as to how the situation is resolved
(i.e., it can *require* further clarification FROM YOU).
There are spots in the house where resolving my location can be
ambiguous -- "is he in the kitchen or the adjoining dining room?".
If the rules regarding how to interpret my current actions/commands
in those two locations *differ*, I have to resolve the ambiguity
"manually". This could be done by clarifying my position to the
system ("I am in the Dining Room"); *moving* so my position is
*less* ambiguous (though it can STILL be ambiguous -- as long as
the ambiguity doesn't cause my action to be interpreted in two
or more different ways); or more explicitly refine the command.
But, there's still no "state" involved -- just "current inputs"
examined, rules scanned, production(s) scheduled, conflict(s)
resolved and, eventually, action(s) taken.
I use state *in* subsystems -- primarily to cache results and
overcome inadequacies in the technologies. E.g., the location
resolution system doesn't make a decision based on "inputs"
tied to your current "location" but, rather, knows what it's
most recent decision was and, assuming it hasn't been told
otherwise, assumes that will be "near" your current location.
If your previous location was "kitchen" and your new location
APPEARS to be "master bedroom", it's simply not possible for
you to have made that change in location that quickly (given
this floorplan). So, it holds off claiming you are in the
master bedroom in the hope that new sensor data will explain
this "error" -- perhaps something has interfered with the
signal path, etc.
Previous location was remembered, so it is part of your 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!)
A "better" implementation that yielded correct data *solely*
from current inputs wouldn't need the "filtering" that my
state variable presents.
This is far too tedious to analyze everything you have written. I
usually don't even read most of it. Brevity is the soul of wit!
And there's never any excuse for ignorance!
If you don't understand something, that's fine...
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.
On 9/16/2014 10:35 PM, rickman wrote:
You can play your mind games, but you have acknowledged that the system
you described has *memory*.
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.
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.
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?]
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.
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).
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.
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!]
Back to my baking...
Like I said, I usually don't read most of your posts because you go so
far afield and just keep going...
On 9/17/2014 12:16 AM, rickman wrote:
Like I said, I usually don't read most of your posts because you go so
far afield and just keep going...
*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...").
On 9/17/2014 3:33 AM, Don Y wrote:
On 9/17/2014 12:16 AM, rickman wrote:
Like I said, I usually don't read most of your posts because you go so
far afield and just keep going...
*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.
On 9/17/2014 12:54 AM, rickman wrote:
On 9/17/2014 3:33 AM, Don Y wrote:
On 9/17/2014 12:16 AM, rickman wrote:
Like I said, I usually don't read most of your posts because you go so
far afield and just keep going...
*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.
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 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.
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).
So the system needs to know more than just the present inputs. It needs
state.
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)
See how short and to the point that was? Your post would have been ten
times as long.
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?"
Like I said, I usually don't read most of your posts because you go so
far afield and just keep going...
*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.
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"?
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.
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.
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).
Obviously you need a "reading the paper" sensor, or maybe a "hands
covered in grease" sensor.
So the system needs to know more than just the present inputs. It needs
state.
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)
See how short and to the point that was? Your post would have been ten
times as long.
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?"
Again, way too long of a post to deal with a simple concept.
On 9/16/2014 3:26 PM, rickman wrote:
More complex systems are not implemented as a single mega-state machine.
Even IEEE-488 bus (GPIB / HPIB) is implemented as a collection of
interacting simple state machines. Don't over complicate the design.
Factor out the separable state machines and define the interactions.
He can call it what he wants, it is still a FSM.
No, it isn't. If you approach it in that manner, you will fail,
miserably.
If it *is*, then identify the *states*.
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.
No. A state machine has state VARIABLES -- *storage*. Where is
the *storage*?
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.