In the theory of Finite-State Machines, an automaton may be in a finite number of states, but only in one state at a time. In an hardware device, interpreted as a FSM, the state corresponds to the values recorded in registers and memories. In a running software, it is the value assumed by all variables. Operators and functions perform transitions between states. In this case, the state is given by all the stored information, at a given time, to which the system has access.
The word state comes from the Latin status, which is past participle of the verb stare - “to stay”, also in the sense of “to stay still”. As a matter of fact, we cannot identify something that we are not able to discriminate from the flow of events. When this is possible, these discrete epistemic entities may be identified as corresponding to states. Following this interpretation, states is what is in between changes.
Furthermore, if we extend the assumption of impossibility of ubiquity, it should be not possible to stay in two different states at the same time. Is it true?
The problem is that state qualifications are easily extended to other frames. For example, we need cash and we go to the nearest Bancomat/ATM. There we found a message: "This device is blocked. We are sorry for the inconvenience". To what extent is the state of the machine blocked? Are we referring in this case to some information stored in the ATM device?
The source of the ambiguity may be explained in this way. At a design level, without considering the actual implementation, the service designer considers functional states like blocked, waiting for a payment card, asking the pin code, etc. At this level of abstraction, the system has been conceived and described using a few states, among which, blocked. Here, the ATM is actually blocked, and block is a state.
But what if we are referring to another level of abstraction? For example, the software level, as software developers do. Is blocked a state? In this frame, not properly. The states of this system are all the possible values assumed by the variables of the program. However, that blocked state may be translated as software states. Empirically, we may collect all combinations of variables occurring when a block state is recognized. This occurs sometimes when a program fails: (partial) dumps of memory are sent through the web. Obviously, there is also an analytic solution. If we analyze the program, we may describe the blocked state as a logical combination of conditions of the variables. This is an example of the logical perspective.
Considering a more formal framework:
A state is a snapshot of the part of the world being modeled at a particular instant of time. State descriptions need to be composed of atomic propositions. This is vital for our purposes since actions typically affect only a small fraction of the environment - and in order to concentrate on this fraction when specifying the effects of an action we need to access to it. Otherwise, i.e., if states are represented as abstract objects without bearing an internal structure (as it is typical for automata theory, for instance), the impact of an action could only be specified by a complete state transition table. This would violate the most fundamental requirement for adequacy. - Michael Thielscher, Challenges for Action Theories (2000)With this definition, describing a world in more than one state at the same time seems to be possible. However, a trace toward a solution to this contradiction is given by the use of the expression "part of the world". The use of a state is strictly related to that system. All ambiguity comes from addressing only implicitly which systemic representation we are using, when talking about the world, or some part of it.
A system, when referred to something existing in the world of experience, corresponds to a layer of representation of reality, defined with a certain structure and behaviour. In general, this behaviour is given by a succession of states and transactions. However, "below" this representation, there is typically another representation, with greater information entropy, and less abstract components. And we may continue to descend, using lower representations, down to perceptions. "Behind" these, there is the actual world.
Interestingly, a disambiguation exists in some domains: when we refer to the marital status, or the status of an application, we are explicitly referring to the state of a certain sub-system, component in these cases of an institutional or service-oriented system.
Still, the problems remains. When we say that in order to cook something, the oven should be powered..
The powered condition is a state of the oven, but what is it, in the higher abstraction level concerning agents and objects? In this case, the word situation may be probably more pertinent, in the explicit sense of combination of circumstances.
Situation comes from the medieval Latin word situare, constructed on top of the word situs. The first meaning is place, but it is also the past participle of sinere, “to place”. As a matter of fact, we, as agents, need to place (or attribute) situations to components (which may be in turn sub-systems) of our representational system, in order to infer something about the world.
Returning to the example of blocked ATM, although the qualification remains the same:
- when we refer to the ATM as a system, blocked is a state.
- when we refer to the ATM as an object in a world system, the block of the ATM is a situation.
