Category Archives: real

HMI Analysis for the CM:MI paradigm. Part 3. Actor Story and Theories

Integrating Engineering and the Human Factor (info@uffmm.org)
eJournal uffmm.org ISSN 2567-6458, March 2, 2021,
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

Last change: March 2, 2021 13:59h (Minor corrections)

HISTORY

As described in the uffmm eJournal  the wider context of this software project is an integrated  engineering theory called Distributed Actor-Actor Interaction [DAAI] further extended to the Collective Man-Machine Intelligence [CM:MI] paradigm.  This document is part of the Case Studies section.

HMI ANALYSIS, Part 3: Actor Story and  Theories

Context

This text is preceded by the following texts:

Introduction

Having a vision is that moment  where something really new in the whole universe is getting an initial status in some real brain which can enable other neural events which  can possibly be translated in bodily events which finally can change the body-external outside world. If this possibility is turned into reality than the outside world has been changed.

When human persons (groups of homo sapiens specimens) as experts — here acting as stakeholder and intended users as one but in different roles! — have stated a problem and a vision document, then they have to translate these inevitably more fuzzy than clear ideas into the concrete terms of an everyday world, into something which can really work.

To enable a real cooperation  the experts have to generate a symbolic description of their vision (called specification) — using an everyday language, possibly enhanced by special expressions —  in a way that  it can became clear to the whole group, which kind of real events, actions and processes are intended.

In the general case an engineering specification describes concrete forms of entanglements of human persons which enable  these human persons to cooperate   in a real situation. Thereby the translation of  the vision inside the brain  into the everyday body-external reality happens. This is the language of life in the universe.

WRITING A STORY

To elaborate a usable specification can metaphorically be understood  as the writing of a new story: which kinds of actors will do something in certain situations, what kinds of other objects, instruments etc. will be used, what kinds of intrinsic motivations and experiences are pushing individual actors, what are possible outcomes of situations with certain actors, which kind of cooperation is  helpful, and the like. Such a story is  called here  Actor Story [AS].

COULD BE REAL

An Actor Story must be written in a way, that all participating experts can understand the language of the specification in a way that   the content, the meaning of the specification is either decidable real or that it eventually can become real.  At least the starting point of the story should be classifiable as   being decidable actual real. What it means to be decidable actual real has to be defined and agreed between the participating experts before they start writing the Actor Story.

ACTOR STORY [AS]

An Actor Story assumes that the described reality is classifiable as a set of situations (states) and  a situation as part of the Actor Story — abbreviated: situationAS — is understood  as a set of expressions of some everyday language. Every expression being part of an situationAS can be decided as being real (= being true) in the understood real situation.

If the understood real situation is changing (by some event), then the describing situationAS has to be changed too; either some expressions have to be removed or have to be added.

Every kind of change in the real situation S* has to be represented in the actor story with the situationAS S symbolically in the format of a change rule:

X: If condition  C is satisfied in S then with probability π  add to S Eplus and remove from  S Eminus.

or as a formula:

S’π = S + Eplus – Eminus

This reads as follows: If there is an situationAS S and there is a change rule X, then you can apply this change rule X with probability π onto S if the condition of X is satisfied in S. In that case you have to add Eplus to S and you have to remove Eminus from S. The result of these operations is the new (successor) state S’.

The expression C is satisfied in S means, that all elements of C are elements of S too, written as C ⊆ S. The expression add Eplus to S means, that the set Eplus is unified with the set S, written as Eplus ∪ S (or here: Eplus + S). The expression remove Eminus from S means, that the set Eminus is subtracted from the set S, written as S – Eminus.

The concept of apply change rule X to a given state S resulting in S’ is logically a kind of a derivation. Given S,X you will derive by applicating X the new  S’. One can write this as S,X ⊢X S’. The ‘meaning’ of the sign ⊢  is explained above.

Because every successor state S’ can become again a given state S onto which change rules X can be applied — written shortly as X(S)=S’, X(S’)=S”, … — the repeated application of change rules X can generate a whole sequence of states, written as SQ(S,X) = <S’, S”, … Sgoal>.

To realize such a derivation in the real world outside of the thinking of the experts one needs a machine, a computer — formally an automaton — which can read S and X documents and can then can compute the derivation leading to S’. An automaton which is doing such a job is often called a simulator [SIM], abbreviated here as ∑. We could then write with more information:

S,X ⊢ S’

This will read: Given a set S of many states S and a set X of change rules we can derive by an actor story simulator ∑ a successor state S’.

A Model M=<S,X>

In this context of a set S and a set of change rules X we can speak of a model M which is defined by these two sets.

A Theory T=<M,>

Combining a model M with an actor story simulator enables a theory T which allows a set of derivations based on the model, written as SQ(S,X,⊢) = <S’, S”, … Sgoal>. Every derived final state Sgoal in such a derivation is called a theorem of T.

An Empirical Theory Temp

An empirical theory Temp is possible if there exists a theory T with a group of experts which are using this theory and where these experts can interpret the expressions used in theory T by their built-in meaning functions in a way that they always can decide whether the expressions are related to a real situation or not.

Evaluation [ε]

If one generates an Actor Story Theory [TAS] then it can be of practical importance to get some measure how good this theory is. Because measurement is always an operation of comparison between the subject x to be measured and some agreed standard s one has to clarify which kind of a standard for to be good is available. In the general case the only possible source of standards are the experts themselves. In the context of an Actor Story the experts have agreed to some vision [V] which they think to be a better state than a  given state S classified as a problem [P]. These assumptions allow a possible evaluation of a given state S in the ‘light’ of an agreed vision V as follows:

ε: V x S —> |V ⊆ S|[%]
ε(V,S) = |V ⊆ S|[%]

This reads as follows: the evaluation ε is a mapping from the sets V and S into the number of elements from the set V included in the set S converted in the percentage of the number of elements included. Thus if no  element of V is included in the set S then 0% of the vision is realized, if all elements are included then 100%, etc. As more ‘fine grained’ the set V is as more ‘fine grained’  the evaluation can be.

An Evaluated Theory Tε=<M,,ε>

If one combines the concept of a  theory T with the concept of evaluation ε then one can use the evaluation in combination with the derivation in the way that every  state in a derivation SQ(S,X,⊢) = <S’, S”, … Sgoal> will additionally be evaluated, thus one gets sequences of pairs as follows:

SQ(S,X,⊢∑,ε) = <(S’,ε(V,S’)), (S”,ε(V,S”)), …, (Sgoal, ε(V,Sgoal))>

In the ideal case Sgoal is evaluated to 100% ‘good’. In real cases 100% is only an ideal value which usually will only  be approximated until some threshold.

An Evaluated Theory Tε with Algorithmic Intelligence Tε,α=<M,,ε,α>

Because every theory defines a so-called problem space which is here enhanced by some evaluation function one can add an additional operation α (realized by an algorithm) which can repeat the simulator based derivations enhanced with the evaluations to identify those sets of theorems which are qualified as the best theorems according to some criteria given. This operation α is here called algorithmic intelligence of an actor story AS]. The existence of such an algorithmic intelligence of an actor story [αAS] allows the introduction of another derivation concept:

S,X ⊢∑,ε,α S* ⊆  S’

This reads as follows: Given a set S and a set X an evaluated theory with algorithmic intelligence Tε,α can derive a subset S* of all possible theorems S’ where S* matches certain given criteria within V.

WHERE WE ARE NOW

As it should have become clear now the work of HMI analysis is the elaboration of a story which can be done in the format of different kinds of theories all of which can be simulated and evaluated. Even better, the only language you have to know is your everyday language, your mother tongue (mathematics is understood here as a sub-language of the everyday language, which in some special cases can be of some help). For this theory every human person — in all ages! — can be a valuable  colleague to help you in understanding better possible futures. Because all parts of an actor story theory are plain texts, everybody ran read and understand everything. And if different groups of experts have investigated different  aspects of a common field you can merge all texts by only ‘pressing a button’ and you will immediately see how all these texts either work together or show discrepancies. The last effect is a great opportunity  to improve learning and understanding! Together we represent some of the power of life in the universe.

CONTINUATION

See here.

 

 

 

 

 

 

 

 

STARTING WITH PYTHON3 – The very beginning – part 3

Journal: uffmm.org,
ISSN 2567-6458, July 10, 2019
Email: info@uffmm.org
Author: Gerd Doeben-Henisch
Email:
gerd@doeben-henisch.de

CONTEXT

This is the next step in the python3 programming project. The overall context is still the python Co-Learning project.

SUBJECT

After a first clearing of the environment for python programming we will now focus a little bit more on the structure of the python programming language. Generally python is not different to any other programming language: there are different kinds of objects and different kinds of operations with these objects, and a certain order how to proceed.

PHILOSOPHICAL CONSIDERATIONS

To be able to write code it is not necessary to do philosophy. But as you will see shortly (and hopefully) it can add some more helpful knowledge by widening your view of what you are doing.

What you want to do while programming is to write some lines of code in the python language to enable some computing process.

Usually you will do this because you have some model in your head which you want to translate (encode, implement) in a python script which can be processed by the python interpreter who talks with the computing machinery.

The computing machinery is some real machine which matches the general (mathematical = philosophical) concept of an automaton called Turing machine.

From a Turing machine we know that one has to distinguish between input values which can be read in and being processed according to a finite set of computable rules and output values of these computations. The output values can also be understood as stored values, which can be read again. Input and output values can have an explicit address of some location where they are stored and a content (= value) at this location. Thus the processing rules can select an address and either read the associated value or write a value into the associated location.

Within this mathematical framework of a Turing machine the values represent objects and the computable rules represent possible operations with these objects.

It is possible to combine elementary values located in individual addresses to more complex values and to combine individual computable rules to more complex operations.

In the first moment this description of a Turing machine can appear  to be too simple to be useful for anything interesting, but as the history of Logic, of Mathematics as well as Computer Science has revealed to us, this simple concept can do anything what we can think of to be computable (a complete different story is that of quantum computers. It has still to be clarified whether the definition of ‘quantum computer’ is compatible with that of a Turing machine).

Taking the journey from a Turing machine to the python programming paradigm as defined in the language then we find a rich set of different types of values as well as a rich set of different types of operations (methods), often object specific.

Let us have a first look to the value (object) types numbers, strings, and sets.

Remark: the following information about numbers you get directly from the python manuals, which you can find associated with the entry for python 3.7.3 if you press the Windows-Button, look to the list of Apps (= programs), and identify the entry for python 3.7.3. If you open the python entry by clicking you see the sub-entry python 3.7.3 Manuals. If you click on this sub-entry the python documentation will open. In this documentation you can find nearly everything you will need. For Beginners you even find a nice tutorial (Alternatively you can have a look to the python web page to the tutorial where you will find this information too).

VALUES (OBJECTS) AS NUMBERS

In our everyday world numbers occur usually as certain symbolic expressions like ’99’, ‘-62’, ‘6.23’, ‘2.3*10^4’ etc. From Mathematics we have learned that there are different kinds of numbers defined which obey different kinds of rules.

Thus we have in everyday life integers, rational numbers, real numbers, irrational numbers, complex numbers to mention the most common types.

While numbers as such have no special meaning they can be used to quantify certain properties like temperature, weight, length, clock-time, velocity, etc.

In python there are three distinct numeric types built in: integers, floating point numbers, and complex numbers. Integers have internally an unlimited precision. Example:

>>> print(23**23)

20880467999847912034355032910567

>>> print(234**23)

3104307401943398225947002752118451297846365869366575104

>>> print(2345**33)

1639509557347018492896272198387903513810572353466749818375721601077990329493344735781232477165758609771728515625

Information about the precision and internal representation of floating point numbers for the machine on which your program is running is available in sys.float_info:

>>> import sys

>>> print(sys.float_info)

sys.float_info(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.220446049250313e-16, radix=2, rounds=1)

Complex numbers have a real and imaginary part, which are each a floating point number. To extract these parts from a complex number z, use z.real and z.imag.

>>> z=complex(2.33,-2)

>>> z

(2.33-2j)

>>> z.real

2.33

>>> z.imag

-2.0

>>> z=complex(2.33,-2)

>>> z

(2.33-2j)

>>> z.real

2.33

>>> z.imag

-2.0

There are additional numeric types like fractions and decimals that hold floating-point numbers with user-definable precision.

The different operations with these numeric types are the following ones:

A population p=1200 citizens increases by incoming people migPlus=500 to 12500.

>>> p=12000

>>> migrPlus=500

>>> pnew=p+migrPlus

>>> pnew

12500

With a birth rate br=0.015 and a death rate of dr=0.018 the population will change in a year like

>>> p=12500

>>> br=0.015

>>> dr=0.018

>>> pnew=p+(p*br)-(p*dr)

>>> pnew

12462.5

If one would assume that the birth br and death dr rates are linearly distributed over the year one could compute some average per month like:

>>> (p*br)/12

15.625

>>> (p*dr)/12

18.749999999999996

The floor operator ‘//’ turns a float number into the next integer which is smaller:

>>> (p*br)/12

15.625

>>> (p*br)//12

15.0

>>> (p*dr)/12

18.749999999999996

>>> (p*dr)//12

18.0

>>>

The remainder operator ‘%’ delivers the ‘rest’ of a division instead of the fraction as in a usual division:

>>> 12/8

1.5

>>> 12%8

4

The ‘abs()’ operator abstracts from possible negative signs:

>>> abs(-7)

7

>>> abs(-7.2)

7.2

The ‘int()’ operator turns a float number into an integer:

>>> int(7.2)

7

>>> int(-7.2)

-7

And the float operator ‘float()’ turns an integer into a float:

>>> float(7)

7.0

>>> float(-7)

-7.0

With the power operator ‘pow(x,y)’ one can raise x to the power of y:

>>> pow(2,3)

8

>>> pow(2,5)

32

>>> pow(3,3)

27

Alternatively one can use the expression x**y:

>>> 2**3

8

>>> 2**5

32

>>> 3**3
27

The next possible continuation you can find HERE.