lecture notes - Kees van Overveld`s

Transcription

1
2
”When Minerva Meets the Centaur”
An Engineer’s Companion to Creative
Problem-Solving
Kees van Overveld
1
version: 1 June 2009
c
1
Kees van Overveld, 2005. Exclusive permission is granted to all students and staff of TU/e to use,
copy, or print this document with the sole purpose to accompany courses on Design Methodology and/or
Modeling. All other usage is strictly prohibited.
2
Contents
1 Introduction
1.1
7
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.1
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.1.2
Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.2
Decision making processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.3
The structure of these lecture notes . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2 Thinking, Creativity, and Thinking about Creativity
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Creativity and Selection
17
17
19
3.1
The instruments in Assist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2
How to get started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3
File IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.3.2
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Sort and Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.4.2
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
Interactive Weights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.5.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.5.2
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Inspire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.6.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.6.2
Auto-ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.6.3
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.7.1
Relations: a fundamental notion in Assist . . . . . . . . . . . . . . . . . .
38
3.7.2
Partial ordering, transitivity and a-cyclic graphs . . . . . . . . . . . . . . .
38
3.4
3.5
3.6
3.7
3
4
CONTENTS
3.7.3
Partial ordering, set-inclusion and ontology . . . . . . . . . . . . . . . . . .
41
Intentional relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Extensional relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Intentional vs. extensional relations . . . . . . . . . . . . . . . . . . . . . .
43
Consistency and propagation . . . . . . . . . . . . . . . . . . . . . . . . . .
43
Partial ordering, comparison and ranking in Assist . . . . . . . . . . . . .
44
Pareto front-ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
Weighted Sum-ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Comparing Pareto front ranking and Weighted Sum ranking . . . . . . . . .
49
Sliders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.8.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.8.2
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.8.3
Sliders for the ’include’ relation . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.8.4
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.9.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.9.2
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.10 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.10.2 Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.11 Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.11.2 Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
3.12 Pareto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
3.12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
3.12.2 Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
3.13 Folk-ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
3.13.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
3.13.2 Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
3.14 Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
3.14.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
3.14.2 Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
3.7.4
3.8
3.9
4 Modeling: a Systematic Approach
4.1
67
The notion of a Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.1.1
Different intentions require different models . . . . . . . . . . . . . . . . . .
68
4.1.2
The role of assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
5
CONTENTS
4.1.3
Multiple models co-exist in any design process; consistency . . . . . . . . .
71
4.1.4
Purposes for models in design . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.1.5
Requirements on models . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.1.6
Variables and relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
Type of a variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
Value of a variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Categories of variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Categories I and II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
Category I : independent, autonomous; Category II : dependent . . . . . . .
74
Finding category-II variables from category-I variables . . . . . . . . . . . .
75
Category-III: contextual variables . . . . . . . . . . . . . . . . . . . . . . . .
79
Category-IV: auxiliary variables
. . . . . . . . . . . . . . . . . . . . . . . .
79
A second distinction between variables in design models . . . . . . . . . . .
80
Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
Cyclic dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
How to deal with constraints . . . . . . . . . . . . . . . . . . . . . . . . . .
83
Educated guesses and models . . . . . . . . . . . . . . . . . . . . . . . . . .
85
Modeling an optimization: multiple category-II variables . . . . . . . . . . . . . . .
87
4.2.1
Pareto plots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
4.2.2
Estimating a Pareto front: evolution theory . . . . . . . . . . . . . . . . . .
89
Pareto: post processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.1.7
4.1.8
4.2
5 Modeling: a tutorial
93
5.1
Generic characteristics of a functional model . . . . . . . . . . . . . . . . . . . . . .
93
5.2
A functional model of a taxi company . . . . . . . . . . . . . . . . . . . . . . . . .
95
6 Modeling: tool support
113
6.1
Nano Accel: supporting the maintenance of functional models . . . . . . . . . . . . 113
6.2
Model manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.3
6.2.1
General Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.2.2
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.2.3
Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Navigation: the run-tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.3.1
6
CONTENTS
6.4
6.5
Index
6.3.2
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.3.3
Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Optimization: the Pareto tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.4.1
6.4.2
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.4.3
Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Visualization: the graph-tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.5.1
6.5.2
Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.5.3
Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
139
Chapter 1
Introduction
’Since we can’t deal with reality, we better get good at modeling’
1.1
Introduction
When the Italian high-renaissance painter, Sandro Botticelli (Florence, round 1445 - ibid., 17
May 1510), painted his famous ’Minerva and the Centaur’ round 1488, he gave a briljant visual
expression to a fundamental psychological theme. It is a theme that dates back to ancient times
and continues to bother academic educational systems until today. In the painting, reproduced
in figure 1.1, we see a confrontation between Minerva, the Roman version of Athena, goddess of
wisdom and crafts, and a Centaur. Centaurs were mythological creatures, half man and half horse,
and they were associated with the god Bacchus. Bacchus, the Roman counterpart of Dionysus,
was the god of wine, ecstacy and unbridled creativity. Minerva and the Centaur can almost be
called archetypes; they represent two rather opposite aspects of the human nature. They both
relate to abilities that can be observed in skillful and competent men and women; both types of
mental attitudes are crucial in all situations of challenge, and every talented engineer or artist will
recognize both aspects in his or her work. Yet, they seem to be of a very different nature. They
are thought to be incommensurable at least, and perhaps even conflicting and mutually excluding.
Professionals with a dominant Minerva-attitude are orderly and systematic; they have an analytic
view to the world and their accuracy and discipline is their strongest tool. Minerva-type problem
situations can be complicated, but they have a clean structure; they allow step-by-step resolution,
and there are few surprises to be expected. Perhaps they could even be called boring, academic
in the negative sense, or unrealistic.
Professionals who feel themselves befriended with the Centaur, on the other hand, get their creative
inspiration from chaos. They excel in artistic environments where intuition flourishes, where
nothing is fixed beforehand, and where mistakes are welcomed as inspiration points for innovative
development. Intuition rather than ratio is their forte.
The Minerva nature and the Centaur nature are both essential in present day professionals irrespective of their field. A long time has passed since engineers were believed to dwell behind
7
8
CHAPTER 1. INTRODUCTION
Figure 1.1: Minerva and the Centaur, round 1488, by Sandro Botticelli: a metaphor for incompatible mental aspects in professionals.
1.1. INTRODUCTION
9
the drawing board, spending their time with slide ruler or pocket calculator. Similarly, designers,
architects and even artists nowadays partake in orderly planned, multi-disciplinary meetings, they
engage in meticulously managed projects, and they use MS Excel as a standard general purpose
computer tool.
But they are educated very differently.
We can interpret Minerva and the Centaur as two metaphors, not only for personal characteristics
or types of problems, but also for education. Ignoring the commonalities, and stressing the difference almost to the level of caricature, we see, on the Minerva side a strongly regulated curriculum
where processes, procedures, and protocols form the core. There is much attention for formalisms
and algorithms, and reasoning goes from techniques to application. Once a sufficient amount of
methods, tools and techniques has been acquired, there is hope that these can be made useful
in practical application - although this often means that the practical problem first has to be
thoroughly amended, massaged, or even modified.
A Centaur-type curriculum is similar to a survival excursion. The chaos of real-life problems forms
the starting point, and techniques are only considered interesting if they can immediately be seen
to lead to satisfied customers or problem-owners. Flexibility, endurance and an unorthodox mind
are considered to be more essential than factual knowledge or theoretical backgrounds.
Even though academic curricula invariably try to join the strengths of both thinking styles, it
is commonly believed that at the level of individual courses, projects or topics, one of the two
always prevails. In a class on linear algebra, the emphasis is on Minerva-style precision and
abstraction; a workshop on architectural design may hinge on Centauresque brainstorming or
guided imagination sessions. Only very few educational work forms attempt to balance - or even:
to reconcile methodology with creativity, formalisms with the chaos real-life problems, or Minerva
with the Centaur. As a result, young professionals are educated in an awkward, split-brain system
where talents and skills, or problems and solutions fall in two incompatible categories: either
Minerva or Centaur.
In the lecture notes you are reading now, we try to develop a coherent system of thinking tools
that aims to bridge the apparent gap between structure and creativity. We will try to convince
you that, incompatible as they may seem at first sight, structure and creativity, when seen as the
modern professional’s tools or working attitudes, in fact have very much in common. They are, to
a large extent, complementary. They mutually reinforce and stimulate each other. Creative ideas
can result from a highly structured process; developing a structured model for a problem at hand
can be a direct inspiration to start seeking for (unorthodox) alternatives, and, conversely, there is
much creativity involved in finding an appropriate structure for approaching a problem. Rather
than the classical distinction between ’structure’ and ’creativity’ therefore, we will encounter the
much more useful duality of explicit vs. implicit. Or, in a more psychological jargon: consciously
vs. unconsciously. Minerva can be interpreted as the aspect of ratio, consciousness and logic
whereas the centaur stands for intuition, pre-consciousness1 and emotionality.
Rather than viewing the two modes ’Minerva’ and ’Centaur’ as a static polarity, as if they were two
mutually exclusive mental characterizations that at best could be complementary but in practice
often lead to debate, envy or wasteful competition, we will focus on the dynamic transition between
the two. We will study various forms of explicitation that lead from intuition to precision, from
fruitful vagueness to even more fruitful concreteness, and from qualitative to quantitative.
We will see how both structured approaches and so-called non-structured ’creative’ approaches
benefit from the process of explicitation. We will demonstrate how it helps to explicitly formulate
assumptions, constraints, and intentions. We claim that is useful to invest in precision about
rationales, dependencies, and options.
Precision is the pathway of the professional.
1 ’consciousness’ can be contrasted with ’unconsciousness’, ’subconsciousness’, or ’pre-consciousness’. All three
are problematic. In line with our arguments later on, we choose for ’pre-consciousness’.
10
problem
type
approach
attitude
main asset
professional
field
main strength
main challenge
prevailing
mental aspect
notorious
prejudices
Minerva
closed
Centaur
open
techniquedriven
analytic
formalisms
and
procedures
engineers,
scientists
reproducibility
’ISO 9000’
whimsical, nonstandard problems
in varying context
problemdriven
synthetic
creativity
and
flexibility
artists,
designers
applicability
ingenuity
routine problems
situations that
require reliable
or dependable
solutions
emotionality or
intuition
chaotic and
non-conclusive;
believed to be
an innate quality
that cannot be
systematically
developed or taught;
results from too
little control.
rationality
boring and
restrictive;
believed to be
the result of
blind drilling in
an unforgiving
school system;
results from too
much control.
Table 1.1: The main distinctions between Minerva and the Centaur
11
1.1. INTRODUCTION
This is by no means a broadly-accepted slogan. Popular belief has it that formalization will kill
spontaneous creativity. Writing down things in some detail in a too early phase allegedly eliminates
options, it is accused of creating a rigid straightjacket of concepts that doesn’t do justice to the
playfulness of the exploring human mind - and most importantly: it is said to jeopardizes intuition.
Intuition is thought to flourish in vagueness.
Artists, designers and architects often boast on their intuition. Intuition, usually understood as
’un-formalized, unconscious knowledge’, relating to non-rational, non-explicit mental processes,
sometimes closely tied to emotions, is seen as the hallmark of non-structured creativity. Intuition
is thought to be a inexhaustible source of inspiration - at least by those who can freely tap
into their intuition. Thinkers and workers with more limited access to this miraculous asset are
sometimes regarded as being mildly handicapped. More intuitively capable sometimes even adopt
a conceited attitude towards rationalists, offering their assistance in the form of suggestions, tips
and techniques to ’stop thinking’ - as if ratio is a poor substitute for lacking intuition.
We will advocate a different position in this debate. We do recognize the value of intuition, but we
regard intuition as a non-explicit, first phase in any process of (creative) synthesis or (structured)
analysis. Hence our preference for the term ’pre-conscious’: this suggests that we deal with a
phase in thinking processes that precedes (or: should precede) explicit statements. A strong
intuition will definitely give a head start to solving any mental challenge, but it requires follow-up
in the form of rational explicitation. In figure 1.2 we schematically sketch the traditional, static
distinction between structure and creativity, and we confront it with the dynamic transition-type
process we want to put in place.
s tru c tu re
( a n a ly s is )
im p lic it, in tu itiv e
th in k in g
e x p lic it, r a tio n a l
th in k in g
- b o th a n a ly tic a lly
a n d s y n th e tic a lly
c r e a tiv ity
( s y n th e s is )
Figure 1.2: Left: the traditional, static dichotomy where (structured) analysis and (creative)
synthesis are seen as complementary or even competing opposites: the engineer vs. the artist.
Right: we want to advocate a thinking attitude where explicitation provides for a transition
between pre-rational intuition and more or less precisely formalized thinking - which applies both
to synthetic and analytic mental processes.
The two key observations to this intended merger of Minerva and the Centaur are design and
modeling.
1.1.1
Design
We use the notion of design in a very broad context. In fact, every situation where decisions are
made for the future benefit of one or more identified customers or stake holders, we will refer
to as ’design’. So a technical artifact can be designed, but also an immaterial object such as an
organization structure, a mathematical formula or a marketing strategy. A composer designs a
symphony, and a chief cook designs an exquisite banquet. You, the reader of these lecture notes,
12
may design the arrangement of the furniture in your living room, a pleasant evening or even your
career; politicians design laws, Utopian visions for a healthy national state or political programs.
Stake holders can be the customers or commissioners or problem owners that initiate the design
situation. But everybody who can be affected by the decisions to be made could (and should) fall
under the definition. In particular, it is inconceivable that the designer her- or himself is not a
stake holder, since many decisions will affect her or his happiness, both during the design process
and afterwards.
Design, in the above interpretation provides a very interesting working context to develop both
synthetic and analytic thinking skills. Indeed, a decision first requires a more or less precise
formulation of what it is to be decided, This is an analytic challenge. Next it requires a proposal
of - preferably several - alternative options. This is a synthetic challenge. The more, and the more
varied options we can conceive, the larger the chance that the solution space will be sufficiently
densely covered, and creativity is primarily engaged in generating many and different solutions
to problems. Finally, taking a decision requires that a justified choice is made for one of these
options, which should be ’better’ than the other ones. Justifying such as choice is again an analytic
challenge.
By dealing with the entire decision making process in terms of one single vocabulary, we see that
the analytic and synthetic aspects need to be integrated. It no longer suffices to interpret them as
isolated professional activities. Therefore, many of the examples we will encounter will be cases
of design, innovation, or decision making.
1.1.2
Modeling
Justifying a decision means that we want to have a reasonable amount of certainty about the
correctness of the decision. We want to know its consequences, and we want to certify that another
decision would not be better. At least we want to understand which line of argumentation was
followed, which assumptions were made, and which circumstances were ignored to arrive at the
decision. As soon as a quest for certainty comes up - however mildly formulated - we are in the
arena of logic. Logic, and mathematics in general, are the paradigms that deal with truth and
probability. Therefore we will find that we will be making a model of the situation at hand.
A model, in this context, is a story, consisting of concepts and relations between these concepts,
that has some correspondence to the situation we want to model. Let us call the situation at
hand the problem domain, DP , as opposed to the model domain, DM . In the problem domain
there is a question, and it is difficult to answer this question in DP only. Therefore we construct
DM . Now DM can consist of material objects. For instance, if we want to know if the air flow
around an aircraft wing will be smooth, we build a scale model of the wing and put it in a wind
tunnel. We observe the wind flow around the scale model, and we try to draw conclusions from
these observations that relate to the air flow around a real, full-size aircraft wing.
More often, however, DM will consist of non-material constructs, such as variables. The relations
between the concepts in DP are mapped to relations between the concepts in DM . In the case the
concepts in DM are variables, these relations can even take the form of formulas. It is important
to realize, therefore, that every formula in DM has a counterpart in DP . The question we want to
be answered in DP is mapped to an intention in DM . A mathematical intention specifies ’what
needs to be done’ with the variables and the formulas. Should they be interpreted as equation
that need to be solved, or should they be seen as a function that needs to be optimized? And if
so, which variables are the unknowns, which variables are known - and how are they known?2
For instance, ’how many check-out counters should we have in a store so that customers don’t
have to wait too long’ is mapped (translated) to a set of mathematical relations, formulated in
2 In
regular mathematical education, intention is often taken for granted. The impression is often held that it
is ’obvious’ what should be done with the mathematical objects at hand. When (applied) mathematics is used in
the context of modeling, however, this is often far from trivial.
1.1. INTRODUCTION
13
the language of mathematics. It may consist of the same variables and formulas as a model
representing the problem ’how long will customers have to wait for a given number of check-out
counters’. Yet another question, leading to the same relations is ’how many check-out counters
should we have so that customers never have to wait longer than twelve minutes’. Or ’ ... so
that customers on average don’t have to wait longer than twelve minutes’. Although there is no a
priori difference between the mathematical formulation in these cases, the difference between the
various intentions is crucial. As a result, the mathematical manipulations that will be done in
the various cases will also be very different. In the first case, we solve an optimization problem;
in the second case, we evaluate a function. The third and fourth cases are subtle mixtures of
optimization and probability theory. In more complex settings, it may not at all be obvious what
exactly the mathematical intention is, and more importantly, how this intention should result into
a mathematical agenda and into a sequence of mathematical manipulations. Even worse: not only
is this far from trivial, it is most often not recognized as a distinct problem in many (traditional)
mathematics curricula.
In mathematics, we deal with things like numbers, lists, probabilities and probability distributions,
rather than check-out counters, rows of irritated customers, and people queueing. The mathematical manipulations (like adding, multiplying, integrating and differentiating) are entirely different
from the types of processes that go on in DP (such as customers stepping into a queue, customers
loosing their temper, customers being served, et cetera). Nevertheless, if the mappings between
DP and PM were meaningful, we believe that a mathematical result (such as ’3.465653264667’) has
a meaning for the situation in PD (namely: ’either 3 or 4 check-out counters should be enough’).
There are three essential, but very different skills involved in making models. Namely:
• the analytic ability to see which are the essential concepts and relations in DP . That is:
which features of the real situation at hand need to be taken into account in order to solve the
problem. For the check-out counter problem: perhaps we need to know how fast a customer,
on average, is served; probably we don’t need to know how much money the customer will
have to pay (since that will not have major influence on how long the process takes);
• the synthetic ability to see what would be plausible concepts in DM to put in the place of the
relevant objects in DP . Once these concepts have been found, the (mathematical) relations
that should apply in DM follow from our understanding from the processes and interactions
between the relevant concepts in DP . These correspondences, however, can never be formally
proven to be correct. They can, at best, be plausible. Indeed, mathematical proofs can
only say something about mathematical objects only, and the correspondences we want to
establish are correspondences between non-mathematical objects and mathematical objects.
For the same reason, the correspondences between objects in DP and mathematical relations
in DM will never be unique. For a given process, relation or mechanism in DP there are
always multiple possible ways to express this in terms of mathematical formula(s). In chapter
5 we will elaborate this point further;
• the formal ability to manipulate the mathematical model in DM . It is very well conceivable
that a perfectly plausible translation between DP and DM gives rise to a completely intractable mathematical problem (for instance, a set of very non-linear equations, or a search
problem with non-polynomial complexity3 ). The required skills to manipulate DM such that
it gives a result that can be mapped back to an answer on the initial problem in DP may be
very different from the skills to develop DM . All too often, a mathematician or computer
scientist will be in place to take care of the formal manipulations on DM ; the problem owner
(the scientist, the designer, the engineer, ... ) will do the actual mapping between DP and
DM and back.
3 We
don’t have to go in to the details of algorithmic complexity here. We just mention that a problem with
non-polynomial complexity is a problem such that a small increase of the problem size leads to a (very) large
increase of the amount of computer time needed to solve the problem.
14
Figure 1.3: three phases in a decision-making process. Left: the item generation phase, where
as much as possible different items (or ideas) should be conceived; Middle: the selection phase,
where the space of all items is reduced to the very few very best ones; Right: the detailing phase,
where the (quantitative) details of the selected idea are defined. The grey polygon on top of the
colored rectangles represents the amount of options at a certain point in time during the decision
making process.
1.2
Decision making processes
We use modeling and design as vehicles to illustrate how creativity and systematic, structured
thinking come together. Therefore we will regard design, in the broad sense of ’taking decisions
such that future benefits of stake holders increase’. This decision making process can be seen as
a three-phase process.
• item generation (or: option generation, idea generation or concept generation). A decision
means that first a (preferably large) number of options has to be available, and these options
have to come from somewhere. They have to be conceived, imagined, proposed, ... . It
doesn’t matter where options come from. We will see that chaotic processes (based on pure
luck) are just as good as systematic approaches, and very often this phase is a mixture of
the two;
• selection. Modeling is an elaborate process, and we typically cannot take more than one
or two options seriously. Therefore, before we can do modeling in detail, we have to select
the most plausible option(s). This selection process therefore must be rather global; still,
we want to follow a route such that our selection can be justified by means of, preferably,
explicit and perhaps objective criteria. We want to be able to explain why we have chosen
one option and rejected another;
• detailing. The preferred option will always contain a (large) amount of details that need to
be filled in. This is the phase where (mathematical) modeling comes in.
Schematically, these phases can be depicted as in figure 1.3. (Notice: in stylized form, this figure
is also part of the logo that precedes every chapter).
1.3. THE STRUCTURE OF THESE LECTURE NOTES
15
In the item generation phase, it is essential to create as many as possible ideas (hence the color4
green: this relates to creativity), and criticism is absolutely forbidden (hence the color yellow: this
relates to optimism).
In the selection phase, initial ideas are critically assessed (hence the color black: this relates to
pessimism or constructive negativism), where criteria should formulated to make intuition more
explicit (hence the color red: this relates to intuition). The large collection of ideas from the item
generation phase needs to be brought back to the very few very best.
In the detailing phase, the few remaining items are cast in the form of (mathematical) models
(hence the color blue: this relates to systematic thinking) and factual information is brought in to
help making realistic estimates for crucial dimensions in the item-to-be-realized (hence the color
white: this relates to objective facts).
The techniques to be used in the various phases can drastically benefit from tool support. We have
developed two tool suites, called Assist and NanoAccel, and we explain the approach in the
various phases by means of the various features of these two tool suites. The tool-stack Assist, to
be described in chapter 3 contains a number of instruments to facilitate the first two phases of the
decision-making process; for support in the detailing phase, the tool NanoAccel (see chapters
4, 5 and 6) may be used.
The emphasis in Assist is much more on qualitative and less formal methods; creative inputs
are stimulated, and the main purpose of the tool is to administrate these in a meaningful way.
We will see, however, that despite the focus on creativity, a systematic way of working will give
welcome structure to the first two phases. In NanoAccel we accentuate quantitative and slightly
more formal approaches. Inevitable, the jargon will be somewhat more mathematics-oriented.
Nevertheless, in chapter 5 we will show that even in this phase of the decision making process,
there is much room for (structured) creativity.
Although the two parts of the process are very different in nature, we will see some techniques
occurring in both. For instance, the emphasis on concepts, attributes and values; also, the notion
of a Pareto-optimum will be a central issue in both parts. We hope to show that throughout the
entire process, there is a constant interaction between creativity and structure.
Minerva and the Centaur will never be far apart.
1.3
The structure of these lecture notes
In chapter 2 we will first give an account of the notion of creativity. Creativity is regarded as
an aspect of mental processes, and therefore our exposition starts with a brief overview of neural
processes as far as they help to understand the peculiarities of creative and non-creative thinking.
More importantly, we will see how some insight in the basic mechanisms of our brain helps to see
why explicitation is of paramount importance in all forms of problem solving, both in analytical
and in synthetical cases. Armed with this basic knowledge we pay attention to the basic ingredients
of creativity: multiple interpretation, forced association, and abstraction, and we describe some
techniques to work on all three. Next we zoom in onto abstraction, as this drives the process of
explicitation that forms the backbone of the rest of these lecture notes. We address some common
aspects of abstraction that will be used throughout, both in decision making and in modeling.
The theoretical ideas explained in chapter 2 can be used in problem solving by means of paper-andpencil techniques, but this will, in practice, seriously constrain the process. Therefore the use of
software support to carry the burden of administration and book-keeping is very much advisable.
To this aim, the software system Assist is devised, and chapter 3 explains how it works.
4 Colors have been chosen loosely in correspondence with the ideas of Edward de Bono about various thinking
attitudes. This is described in his books about ’thinking hats’.
16
After having discussed the qualitative aspects of problem solving, in terms of option generation and
selection, in chapter 3, we move to the quantitative aspects in chapter 4. We present a template
for building models to support decision problems in a systematic fashion. The key observation
is the notion of intention; we will see that, in the case of design processes, and decision making
processes in general, intentional reasoning leads to an iterative process for identifying variables
and their relations.
The theory of chapter 4 is illustrated by means of a detailed, worked-out example in chapter 5.
This example is given in sufficient detail that it can be run on any standard spreadsheet program.
However, it has even more educational value if it is run on MS-Excel with the tool NanoAccel.
The tool NanoAccel is described in detail in chapter 6.
Chapter 2
Thinking, Creativity, and
Thinking about Creativity
’Since our brain runs patterns, we’d better make it run creative patterns’
2.1
Introduction
This chapter is not yet available.
17
18
CHAPTER 2. THINKING, CREATIVITY, AND THINKING ABOUT CREATIVITY
Chapter 3
Creativity and Selection
’All good things are three’
3.1
The instruments in Assist
Assist is an acronym for Assist Supports Systematic Innovation by means of Software Tooling. It
is intended to support a process of option generation, adminstration, and evaluation. Options are
represented in a way that allows easy comparison and ranking; also, the creation of novel options
out of existing ones is addressed. The central idea behind the tool is to help getting insight in the
structure of the option-space, rather than seeing all options as isolated creative solutions. Option
spaces in Assist can be exported and re-used in other projects; in fact, Assist offers an interface
to a growing, web-based ontology of world knowledge to which everybody can contribute, and
where everybody can get inspiration from.
The instruments currently available in Assist are the following:
• The Data Grid: this is a table where all items live. An ’item’ here, is any idea that comes up
during the creativity process, and that is to be assessed in the selection process. Items are
rows in the table; its columns either represent classifiers or ranking attributes. Classifiers
are used to characterize an item in terms of its properties. These properties are, generally
speaking, qualitative features. Classifiers serve to distinguish one item from another: the
difference between two items will reflect in the difference of the values of at least one classifier. In subsection 3.4.1, a more detailed introduction into classifiers is given. The ranking
attributes (or ’attributes’ for short) characterize an item in terms of its adequateness. Ranking attributes help to tell if one item is better suited for its purpose than another. Classifiers
and ranking attributes can be added at any time; they can be deleted if no longer necessary,
and their name can be changed at will;
• File IO: create a new project which is initially empty, or load an existing project from an
earlier session, or write the current project to background storage for future processing;
19
20
CHAPTER 3. CREATIVITY AND SELECTION
• Sort and cluster: by their nature, classifiers serve to distinguish one item from another. We
could say that classifiers together form our frame of knowledge about the space of all items:
both the items in our list, and the items that do not (yet) occur in the list, but that could
be conceived as alternative possible ideas. In order to study the structure of this space, we
can apply various quantitative analyses, for instance to compare the distinguishing power of
classifiers, or to assess whether classifiers are sufficiently independent. Readers familiar with
non-parametric statistics may recognize some of the features of the ’sort and cluster’-tool;
• Interactive Weights: this allows interactively changing the relative importance of each of the
ranking attributes;
• Inspire: create new items, either from scratch, either as a result of an inspiring suggestion,
or either as a result of systematic, new combination of values for classifiers;
• Relations: there are various types of relationships between items. One type of relationship
has to do with classifiers. This is the ’is-a’ relationship, also called hierarchy: an apple
is a (piece of fruit), and a hammer is a tool. Often the space of possible ideas can be
conveniently structured by making hierarchies explicit. The other type of relationship is the
’inferior with respect to’-relationship. For instance, a motorcycle is an inferior means for
transportation than a bicycle with respect to CO2 -emission. The latter type of relationship
will be extensively used in the selection process;
• Sliders: see real-time consequences of varying the relative importance of ranking attributes;
• Questionnaire: an intuitive means to assess the relative adequateness of items;
• Query: navigate the list of items by means of database-like queries;
• Cluster: to aid the interpretation of the structure of the present set of items, their classification and their attribute-ranking can be explored by means of intuitive visualization;
• Pareto: to aid the analysis of relative qualities of the present set of items, they can be
visualized as points in a plane spanned by a pair of criteria, where any pair of criteria can
be selected;
• Preferences: to adjust the global behavior of Assist;
• Folk-ontology: this gives an interface to a growing, web-based ’folk ontology’ on world
knowledge;
• Registration: to run the web-based version of Assist, users must register (get an account)
and login in order to do input and output, and to contribute to the folk-ontology. The
functionality of the registration tool is not covered here.
In the sequel, each of the tools is described in detail.
3.2
How to get started
Assist consists of the Data Grid plus a series of interactive forms, each form representing one
of the tools. The forms allow processing of the information contents in the Data Grid; the Data
Grid, however, can also be manipulated directly. In particular, values for classifiers can be typed
in directly into cells in the Data Grid. Figure 3.1 shows the Data Grid and the related buttons.
The Data Grid plus all of the forms together form a Flash-application, to be run either as a
web-application in a browser, or as a stand-alone desktop application (a so-called Adobe AIRapplication). The two versions are identical up to one crucial difference: the File IO functionality
3.2. HOW TO GET STARTED
21
Figure 3.1: The Data Grid and related buttons. The actual row is the item ’coffee’, the actual
column is the classifier ’cont...’(contains alcohol)
22
is only available in the desktop version, since security considerations forbid storage and retrieval
of file data from within a web-application. Instead, the web-version supports saving and loading
information onto a web-database. Access to this database is granted for users who have registered
and logged in. To this aim, the web-based version of Assist contains one additional form, called
’manage registration’. This form allows to create a new account, to log in on an existing account,
to modify an account (e.g., to change the password), and to ask for a new password in case the
password has been forgotten. The operations of the ’manage registration’ form are very much
compliant with standard www-practice; these are not covered further.
One further difference between the web-based version and the stand-alone version is in the way
projects are saved and retrieved. In the stand-alone version, projects are files that are maintained
at the local file system of the computer running Assist. This means that e.g. deleting files is
handled by the local operating system (e.g., Windows). Selecting files takes place via a standard
file-browser. For the web-based version, the role of the file system is played by a remote database;
registered users have access to this database - and this is the only way the project data is available.
A maximum amount of projects is allowed for each registered user; deleting projects is controlled
via a additional ’delete’-button in the File IO form (see later) of the web-version of Assist; this
function is not present in the stand-alone version.
When running the stand-alone version, this has first to be installed. The installation of such a
so-called Adobe AIR-application, although straightforward, is not covered in these lecture notes.
In the sequel it is assumed that either a working version of the AIR-version of Assist is up and
running, or Assist is approached via the web in a browser.
Assist’s Data Grid is permanently visible. Rows or columns to the Data Grid can be added,
renamed or deleted by means of a set of 9 buttons in the upper row of the application. Buttons
carry the name of the rows or columns that they operate upon. The left three buttons cover
adding, deleting or changing items; the middle three adding, deleting or changing classifiers, and
the right three adding, deleting or changing ranking attributes. At any time there is an actual
row and an actual column. The actual row relates to an item; the actual column can either relate
to a classifier or to a ranking attribute. A row becomes the actual row by clicking into a cell of
that row; a column becomes the actual column by clicking into a cell of that column.
The Data Grid always contains at least two columns. One column is labeled ’itemName’ (the leftmost column), and the other column is labeled ’itemRank’ (the second column). The itemNamecolumn contains the names of the items; the itemRank-column contains an indication of their
adequateness - in terms of numerical values or a color code.
The itemName column and the itemRank column cannot be removed or renamed; all other
columns, holding classifiers or ranking attributes, are dynamically created under direct user control.
In some cases, some operations are not available. For instance, when clicking into a cell in the
itemName or itemRank column, the ’delete’ or ’rename’ operations for columns are not available.
Buttons for non-available operations are made invisible.
The top row of the Data Grid is the row of column headers. In the column headers, we find the
following information:
• the word ’itemName’ to indicate the column with item names;
• the word ’itemRank’ to indicate the column with values indicating the adequateness of the
items;
• the name of a classifier with the set of values for that classifier in parentheses for any classifier;
• the name of a ranking attribute with the relative importance of that ranking attribute in
parentheses for any ranking attribute. Column header cells for ranking attributes carry a
3.2. HOW TO GET STARTED
23
color code; red means ’little importance’; yellow means ’average importance’; green means
’much importance’.
By clicking into any column header cell, a sort-widget appears. This sort widget contains three
buttons, labeled ’up’, ’down’ or ’-X’-. Clicking the ’up’-button causes the rows to be sorted
in increasing direction for the values in the corresponding column; the ’down’ button sorts in
decreasing direction. For classifiers and item names, sorting is in lexicographical order; for the
item ranking and attribute ranking, sorting is in numerical order. The ’-X-’ button serves to cancel
the sorting tool.
The left-to-right order of columns is by default the order of their creation; the width is by default
set to a standard width. Columns can be dragged into a different order and the widths can be
adjusted, however, by means of dragging the column header cells or dragging the borders between
subsequent column header cells, respectively. This can be useful, for instance, if there are many
columns so that the standard width is too narrow ro read the entire classifier or ranking attribute
names.
Items, classifiers or ranking attributes can be added at any time when there is no other form
present. Item names must be unique; some other syntax requirements apply (for instance, there
are some forbidden characters), but users are warned if a name is given that is not acceptable.
Column names (either classifiers or ranking attributes) must also be unique, and they also must
obey some syntax requirements; users are warned if these restrictions are violated.
To build up an ontology in Assist, items and classifiers need to be entered. Entering a classifier is
done by clicking the ’add classifier’-button above the Data Grid, typing a new name, and hitting
’enter’. Thanks to the underlying folk-ontology, Assist knows the meaning of a growing list
of classifiers that have been entered by earlier users; classifiers from these list should preferably
be chosen in order to make an ontology that is compatible with the folk-ontology. Therefore,
inputting a classifier name is supported by completion-as-you-type. Instead of typing the full
name of a classifier, a classifier from the shown list can be selected. The same mechanism applies
to items.
Right next to the Data Grid there is a series of buttons, each labeled with the name of one of
Assist’s tools. These buttons are only visible when no tool is active: when a form appears and
its associated tools starts, all buttons are made invisible. This means that at any time, at most
one tool can be active.
Every tool is implemented as a form, containing the name of the tool in the upper left corner, and
an ’X’ in the upper right corner. Clicking on the ’X’ closes the form and quits the corresponding
tool.
Most forms can be dragged to a convenient place in the application by left-clicking somewhere
into the form and moving the mouse with the left button down.
In a form, we find various controls such as buttons, sliders and check boxes. In most tools, these
are enabled and disabled in a context-sensitive way. This means, that in any given state, only
those controls that have a meaningful usage are clickable, and have effect. Controls that have no
effect are invisible.
The desktop version of Assist allows a current project to be saved and reopened for further
working. To this end the contents of a project are written into a .amf file.
Although Assist is designed and implemented to be as robust as possible, there is always the
possibility of a runtime crash (perhaps due to external circumstances, such as power failure). To
protect the user against data loss in such events, the desktop version of ASSIST frequently stores
the current project in the form of a backup file, with extension .bu amf to the current directory.
With the recover function in the File IO manager, this back-up file can be loaded for further
processing.
24
The creation of automatic backup files assumes that the current project has been given a name.
Therefore it is recommended, immediately after starting a new project, to save this project, thereby
giving it a name. If an unsaved project exists, Assist will frequently prompt the user to save it
for the first time.
Although all processing takes place via the various forms of Assist, the .amf-files and .bu amffiles can be opened by any regular text editor. Modification of these files outside Assist may
jeopardize their integrity, though, which can cause Assist to fail. Under normal circumstances,
therefore, the .amf-files and .bu amf-files should never be edited, and loading any modified .amf-file
or .bu amf-file should not be attempted.
In the sequel, we describe all the separate ASSIST tools.
3.3
3.3.1
File IO
Introduction
There is a number of different reasons to save projects. One may want to share one’s work with
other people; one may want to preserve the work put into a project for later continuation, or
one may want to export the information to (future) other applications. In most applications, all
functions are combined in the notion of files. The web-based version of Assist, however, cannot
use files in the standard way: as a security policy, Adobe forbids online Flash applications to have
access to the client-side file system. Therefore the permanent representation of Assist projects is
implemented in a number of different ways, to work-around this lack of files.
objects stored in a remote database: registered users1 have a fixed amount of database storage space allowed on a remote server. Saving Assist projects as records in this database has
the advantage that these projects can be accessed from anywhere on the globe. There are
two disadvantages, however: the amount of space per registered user is limited (currently to
10 projects per user); furthermore, since a project is converted into the database by means of
an URL request, limitations apply in relation to the local URL facilities - which depend on
server settings and the local browser used. As a consequence, the size of an Assist project
may be too much for successful storage to the database.
objects stored in shared memory: if a user has admin-permissions on his/her local machine
(which is usually the case for privately-owned machines), Flash applications can write persistent data to hard disk in so-called ’Flash-cookies’. These are similar to common Web-cookies,
with the exception that they do not expire. These Flash-cookies can be thought to emulate a
(small) local filesystem, that is fully separated from the main file system for security reasons.
Assist projects can be saved in such a Flash-cookie. This means that this project is accessible to any user of the computer that has admin-permissions. The size of a Flash-cookie is
limited, but it will expand upon request (in that case, a dialogue pops up). Using this local
storage strategy is advised for Assist projects that need not to be shared among machines;
to a single project, no size limitations (normally) apply. The disadvantage of this approach
is, that Flash cookies are difficult to communicate to other machines (unlike standard Webcookies, their location in the computer’s file system is not always predictable and somewhat
obscure).
XML-objects, imported and exported by means of the copy-and-paste technique: to store
Assist projects in such a form that they can be easily administrated, shared with other
users, and be exported to (and imported from) other applications, there is an XML format
1 registration, authentication and login are only features of the web-based version of Assist; details of the
registration and authentication process are not covered in depth here.
3.3. FILE IO
25
for Assist projects. Projects in the XML format, however, can only be exported from and
imported into Assist by means of the standard copy-and-paste functionality. This means
that an XML-version of an Assist project should be saved in a standard text file and opened
in a standard ASCII-editor such as WinEdt, Notepad++ or similar. Then the entire text
should be selected and pasted (ctrl-V) from the copy-and-paste buffer into Assist. Similarly,
exporting an Assist project causes it to end up in the computer’s copy-and-paste buffer,
where it can be pasted into a text editor and handled further like any standard text file.
Remote files: apart from the remote database, there is also a (limited) amount of remote disk
space reserved for saving Assist projects in the form of files. This is similar to the option
where projects are stored as objects in a database, but the limitation of URL requests lengths
does not apply. Currently, this is the preferred option to save and retrieve Assist projects;
it is set as the default option in the preference manager.
Which of the three modes is used to perform the input-output functionality of Assist can be set
in the Preference tool.
In the sequel we make no difference between the three modes for input-output; we pretend that
Assist projects are simply stored as if they were files on a local file system.
A new project starts by activating the New-function. This clears the Data Grid and the internal
data structures. In order to prevent valuable information from a previous run to get lost, the user
is asked to confirm clearing the current Assist-model. Notice: this form is only available in the
desktop-version of Assist.
3.3.2
Manual
The form is given in figure 3.2. This form pops up if the user clicks the File IO-button right from
the Data Grid.
The following controls are available.
new
In order to start a new project, the new button should be clicked. If an unsaved project exists,
the user is asked if this should be saved first.
open
This opens a standard MS-Windows file browser which allows to navigate the file system and to
select an existing ’.amf’-file to be read in. In case an unsaved project exists, the user is asked first
if this project should be saved.
save
In order to save the current project under its current name, the save button should be clicked.
This replaces the existing file on disk with the current name by the current contents of the project.
save as
In order to save the current project under a new name, the save as button should be clicked. This
pops up a standard MS-Windows file browser which allows the user to navigate the file system
and to select an existing filename or to type in a new name. If an existing file is given, Assist
asks for confirmation first. Notice that the typed-in file name should have no extension; Assist
automatically extends the given filename with the extension ’.amf’.
recover
In case Assist terminated in case of a crash, the most recent version of the current project may
not have been stored. In that case, a back-up version of the previous version of the project may be
26
Figure 3.2: The File IO form. The current project, which contains 1 item, 1 classifier and no
rank attributes has not yet been saved and therefore has no name yet. (This is the version of the
web-based edition of Assist; the ’Delete’ button is absent in the stand-alone edition.
loaded. Clicking the recover file button allows the user to load files with the extension .bu amf,
i.e., Assist backup files.
delete
Deleting obsolete projects takes place in the stand-alone version by deleting the files in the file
system of the local computer. For the web-based version, this is not possible; there obsolete
projects have to be deleted in the (remote) database. The delete button puts up a list of current
projects; the project-to-be-deleted can be selected in this list.
Notice: the four different save-and-retrieve modes, supported by Assist all use the same dialogue,
and therefore the same form layout, for new, open, save, save as, recover and delete, with the
exception of the XML mode. For exporting and importing projects as XML-files, not all operations
are meaningful.
current status
This text field gives the information of the currently opened project: its title (=the name of the
file on disk, including the full path, if there is a current file), the number of items, the number of
classifiers, the number of attributes. The current status field cannot be edited.
3.4
3.4.1
Sort and Cluster
Introduction
We study the following design problem: a manufacturer for hardware tools produces a large
variety of equipment: hammers, saws, drills, pliers, . . . To increase the market, they consider to
expand their product range. A traditional way to do so is to set up a brainstorm - however, the
results from a brainstorm are just a haphazard collection of samples of an infinitely large space
of possibilities. It would be much more efficient if we could provide this space with a map, or a
system of coordinates that would allow systematic navigation. That would help us to find empty
regions, i.e., options for innovation or expansion.
Such a coordinate system, or ontology, can be found if we endow the space of possibilities with
orthogonal, operational classifiers,
where for each classifier the set of values can be finitely
enumerated.
3.4. SORT AND CLUSTER
27
We explain each of the terms classifier, orthogonal, and operational in more detail.
A classifier is a function that maps an item to the value that is assumed by the classifier when
applied to the item. For instance, the classifier ’color’ maps a cucumber to the value ’green’, and
a banana to the value ’yellow’.
Two classifiers are said to be orthogonal or independent if all combinations of their values can
occur; ideally, if they all have more or less equal probability to occur. In other words, if the value
of one classifier does not predict the value of the other classifier. For instance, ’contains sugar’,
with values ’much’, ’little’, and ’no’ is a strong predictor for the classifier ’taste’, with values
’sweet’, ’sour’, ’bitter’ and ’salt’, since food that contains much sugar tastes sweet. Therefore,
’contains sugar’ is not very orthogonal to ’taste’. On the other hand, sweet-tasting objects appear
in all sorts of colors. So ’taste’ is presumably quite orthogonal to ’color’.
A classifier is operational if it applies to all items in the considered domain. For instance, if
’software’ would be one of the tools in the list, the classifier ’weight’ would not be operational,
since software cannot be mapped to an amount of kilograms (it can be mapped to an amount
of kilobytes, though . . .). If finding the value of a classifier when applying it to an item of the
list requires a substantial amount of discussion, this often means that the classifier is not very
operational.
Finally, a classifier is said to have a finitely enumerated set of values if we can produce a list of all
outcomes of that classifier. A trivial case is a Boolean classifier that can only assume the values
’true’ or ’false’ (such as the classifier ’is legal’, ’is a banana’, ’is driven by a motor’, ...). A nice
example of a 3-valued classifier with values that can be enumerated is ’aggregation phase’, with
values ’gaseous’, ’liquid’, or ’solid’. But classifiers such as ’shape’ or ’is used for’ are not finitely
enumerated.
Finding classifiers is not trivial, and finding classifiers that are reasonably orthogonal is sometimes
quite tough. Still, the endeavor is worth the effort. Indeed, if a good set of classifiers can be found
for a given domain (in our example, the domain of hardware tools), this set of classifiers can be
said to represent (a substantial part of) the world knowledge or domain knowledge or ontology
underlying the list of items. Such a set of classifiers, among other things, can be used to see if
new combinations of values might yield a novel product. Perhaps even more importantly, the
construction of a set of (good) classifiers is a very instructive way to gain understanding of the
structure of the set of items for which these classifiers apply.
A ’good’ set of classifiers for any given set of items should be sufficient to distinguish all items.
Indeed, if a present set of classifiers is insufficient to distinguish any pair of items, whereas we
know that these two items are different for some reason, we can argue that there is still some
chunk of our world knowledge that is not yet captured in he set of classifiers, and it is challenging
to try to find the associated missing classifier(s).
At the same time, a ’good’ set of classifiers should be as small as possible. Indeed, for every next
classifier the requirement of (near) orthogonality with all earlier classifiers is increasingly more
challenging, and the fewer classifiers are needed, the least redundancy has to be coped with. (Two
classifiers are said to be redundant if they are not very orthogonal).
Finding a good set of classifiers is partially a matter of creativity, and the ability to think in abstract terms about an application domain. It is, however, also an administrative burden: verifying
the orthogonality of two (meaningful) classifiers is a matter of verification, bookkeeping and calculation. The latter task, therefore, can and should be automated, thus permitting the (human)
user to focus on the first task.
The Sort and Cluster-tool forms the component in the Assist-toolkit that performs the administrative duties of building orthogonal sets of classifiers.
A newly created classifier has no values. Every time, however, one or more values are entered into
a cell in the newly created column, it is understood that this / these value(s) is one of the possible
28
values for the new classifier. All these values are collected and put between parenthese behind the
name of the classifier in the column header.
For entering values into classifiers, Assist makes use of the folk-ontology whenever possible. That
means that a list of possible values for a classifier is shown when a cell is clicked in the column
of some classifier. If the number of values for this classifier is large (for instance, with generic
classifiers such as ’purpose’ or ’disadvantage’), the list operates in the same completion-as-youtype mode as explained before. Otherwise, values can be simply selected from the list; when
multiple values are needed for a single item-classifier, these need to be separated by comma’s.
Assist can deal with arbitrary numbers of classifier values per classifier. In practice, large sets
of values are rare, however; they typically indicate a classifier that is not very well defined. In
particular for beginning users, it may be a good idea to try and find two-values classifiers (classifiers
only allowing the values ’yes’ and ’no’, for instance).
The classifiers together with the (sets of) classifier values for all items form the ontology of the
collection of possible ideas . Classifier values are assigned to item-classifier combinations by simply
typing the classifier values directly into the cell of the Data Grid. The contents of a cell can be
one of the following:
• if no values are present, this means that the selected classifier has no meaning for the selected
item (for instance: the classifier ’temperature’ with values ’hot’ and ’cold’ is applied to the
item ’piano concerto’); or: the set of values of the classifier is not complete (for instance:
suppose a classifier ’aggregation state’ has values ’solid’ and ’liquid’, and it is applied to
’vapor’ (which is a gas state), then no value must be given);
• if more than one value is given (in a comma separated list), the interpretation is that apparently the item refers to a class of things; several of these things classify as various different
values for the classifier;
• if exactly one value is given, it is possible that the item refers to a class of things, where all
items of the class classify as the same value for the actual classifier; it is also possible that
the item refers to a single, unique thing, and obviously the value for the actual classifier
represents the value of that classifier for the single unique thing.
The ontology is complete if, for every item in the item-list, the values for each of the classifiers are
given in one of the above ways. Then, the world knowledge about the items is formally represented
in Assist. Once this information has been represented in Assist, we can use this information in
various ways:
• we can verify if the collection of classifiers is sufficient to distinguish all items;
• we can check if the various classifiers are sufficiently orthogonal (independent) to form a
meaningful and concise representation of the underlying world knowledge;
• we can automatically generate new combinations of classifier values that might inspire to
new items; this is done using the substitution or invention buttons on the Inspire-tool;
• we can express the notions of extensional is-a relationships (see 3.7.3) between items. For
instance: an item ’car’ where classifier ’number of wheels’ takes the value ’4’ is a special case
of an item ’vehicle’ where the values are 2, 3, 4, or ’more than 4’. By inspecting the (sets
of) value(s) for all classifiers for two items, A and B, we can conclude whether A is a special
instance of B, whether B is a special instance of A, or whether none of the two is the case.
(We give a more elaborate discussion of is-a relationships when we discuss hierarchies in the
section explaining the Relations-tool, 3.7);
29
Figure 3.3: The Sort and Cluster-tool. The ’sort’ button has been clicked, and the items in the
Data Grid have been sorted in lexicographical order with respect to their classifier values. Items
have been colored in accordance to whether they are distinguishable with their predecessors and
successors. Clusters of non-distinguished items are therefore visible as single-colored chunks in the
table. Notice, for example, that on the basis of the current set of classifiers and classifier values,
’bread knife’ and ’hand saw’ cannot be distinguished.
30
• we can automatically cluster the items in the list. One form of clustering is provided by
lexicographic sorting: we put the classifiers in a desired order, and next sort the items with
respect to their value for the first classifier; if several have the same value for this classifier,
these are sorted with respect to the second classifier, and so on - until we can assess if all
items are distinguishable with the present set of classifiers or not;
• we can access the list of items, and form meaningful selections, on characteristics that are
expressible as (constraints) on values for classifiers. This is supported by means of the
Queries form (see 3.10).
3.4.2
Manual
The Sort and Cluster-form looks as in figure 3.3.
Depending on the settings in the Preferences form, various additional circumstances can apply to
setting values for classifiers, related to hierarchies. These are explained in the section on Relations
(see 3.7.3).
Sort The Sort button performs two actions. First, it performs a lexicographical sort of all
items with respect to the classifiers in their present order. Next, it applies a coloring scheme to
the concepts. Every row is colored on the basis of the values of the classifiers in that row. If two
subsequent rows are identical with respect to the values of the active classifiers, they receive the
same color, otherwise they are colored differently. In other words: two subsequent rows with the
same colors indicate two items that are indistinguishable as far as the present active classifiers
are concerned. From the resulting coloring, it is immediately clear if groups or clusters of items
exist that are indistinguishable with respect to their classifier values: they appear in single-colored
bands, whereas items that are distinguishable from all other items have a color that differs from
their successor and predecessor. Sorting can be used for two purposes:
• to verify if a present choice of classifiers is sufficient to represent all distinctions in the domain
of items;
• in case there are clusters of indistinguishable items, it shows which these clusters are. So,
when inventing a next classifier, the user can focus on the items that should be distinguished
by means of this new classifier. It is often a good idea to focus on the largest cluster when
seeking a new classifier: which classifier could help splitting the largest cluster in smaller
clusters?
Every time when classifiers have been added or removed, sorting could be done to update the
information about whether or not the current set of classifiers is sufficient to distinguish all items.
Sorting obviously will affect the order of the items; this ordering is propagated consistently to all
other tools in Assist that deal with (lists of) items.
Correlate classifiers
Every active classifier can be assessed in terms of its ability to single out concepts. For instance,
a Boolean-valued classifier that scores 9 out of 10 cases ’true’ and only once ’false’ gives much less
information than a classifier that gives a 5-5 score. The former boolean attribute as not very well
balanced ; the second one is.
Also for classifiers with more than 2 values, Assist can compute how well the classifier balances.
Ideally, every value occurs exactly the same amount of times. In that case, the imbalance is said
to be 0. This is the best possible situation with respect to balancing. The other extreme is the
hypothetical case where a classifier only produces a single value (in which case it doesn’t contain
any information at all). In that case the imbalance is said to be 1.
31
Figure 3.4: Example of the result of clicking Sort and Correlate classifiers. The correlation
matrix shows that classifiers ’movement’ and ’impulse’ are poorly distinguished. They are rather
dependent: the color of the cells is orange. Further, the classifiers ’dividing’ and ’teeth’ balance
well, which is indicated by the green color of the cell. Correlation allows to distinguish ’good’
classifiers (low values in the matrix) from ’bad ones’; an indication for the ’goodness’ (or ’badness’)
of each individual classifier is given by adding the values in one column and color-coding the result.
This is seen in the lower most row in the above table.
The better an attribute balances, the more information it gives. Indeed, suppose we have n items.
The worst possible balance is obtained if one item belongs to one class, and n − 1 items belong
to the alternative class. This can be realized in precisely n different ways, because each of the n
items can be the one who is singled out. The best possible balance, assuming n even, is obtained
if half of the items belong to one class, and the other half to the alternative class.
The
number
n
of different ways a class of n individuals can be split into two equal halves is
= nn!
n ,
2!2!
n/2
for even n. For instance, for n = 4, the amount of possibilities for balanced partitioning is 6;
for (fully) unbalanced partitioning this amount is only 4. Obviously, for sufficiently large n the
latter gives immensely more possibilities, so a single boolean attribute contains immensely more
information when it gives a balanced partition.
For any combination of two classifiers, say V and W , we can express how independent they are.
To this aim, we average the imbalance for classifier V for each of the values of W , weighted with
the number of occurrences of these values. For instance, consider the following case:
value V1
value V2
value V3
value W1
20
3
4
value W2
3
3
4
This table represents the classifier values for 20+3+3+3+4+4=37 concepts. The combination
where classifier V takes the value V1 and classifier W takes the value W1 occurs 20 times, et
32
cetera. For value W2 of classifier W , we see that V is reasonably balanced. In order to quantify its
imbalance, we introduce a function of two vectors, called the normalized dot product, which can be
interpreted as the cosine of the angle of the two vectors, say a and b. This function is abbreviated
as dot(a, b). In the case of 1-dimensional vectors (that is, the vectors are just numbers, say x and
y), we define it as
dot(x, y) = 2
xy
,
x2 + y 2
which can be seen to vary between -1 and + 1. So it nicely corresponds with our intuition of the
cosine of an angle. With this definition, the imbalance of the list of scores (3,3,4) is defined as
1 − cos φ where
φ=
arccos(dot(3, 3)) + arccos(dot(3, 4)) + arccos(dot(4, 3))
0 + 0.28 + 0.28
=
= 0.19,
3
3
and the imbalance is 1 − cos 0.19 = 0.017. For value W1 , however, the numbers of occurrence of
values V1 , V2 , V3 of 20, 3, 4, respectively, cause a much larger imbalance: φ = 1.013, so 1 − cos φ =
0.47. The number of occurrences of W1 is 20+3+4=27 and the number of occurrences of W2 is
3+3+4=10, so the weighted average of the imbalances is (27 ∗ 0.47 + 10 ∗ 0.017)/(27 + 10) = 0.34.
Since a measure for independency should be commutative, we also compute the weighted average
for the transpose case:
value W1
value W2
value V1
20
3
value V2
3
3
value V3
4
4
With a similar procedure we find the value of 0.48 here. The final value for the independency of
V and W is therefore (0.34+0.48)/2= 0.41. If this value is (close to) 0, the classifiers are (close
to) independent.
Clicking the button Correlate classifiers computes the imbalance for every classifier and the
independency for every pair of classifiers, and compiles this information in a (symmetric) matrix,
as follows (assume classifiers V , W , and X)
V
W
X
V
imbalance
of V
independency
between V and W
independency
between V and X
W
independency
between V and W
imbalance
of W
independency
between X and W
X
independency
between V and X
independency
between W and X
imbalance
of X
For an ideal case, where all classifiers are perfectly balanced and all pairs of classifiers are perfectly
independent, all entries in he matrix are 0. In the worst case, entries are 1. For easier reference,
cells are color encoded: green means very good (very small values); yellow reasonably good; orange
not so good and red means very large (very bad) values. Using the values in this matrix, we can
define a quality for a classifier, being the sum of the values in the column associated to that
classifier. For instance, the quality of V is the sum of the imbalance of V plus the independency
between V and W plus the independency between V and X. After having computed all imbalances
and all independencies. See figure 3.4 for an example of the correlations matrix.
Notice: the above explanation assumes that all classifiers have a single value when applied to an
item. The case where items can have multi-valued classifiers is treated completely analogously.
3.5. INTERACTIVE WEIGHTS
33
Correlate attributes
Apart from the classifiers, items are also distinguished by means of ranking attributes. Although
we haven’t yet explained the mechanisms related to ranking, we can mention here that a fully analogous procedure can be followed to assess the ’quality’ (in terms of balancing and distinguishing)
of ranking attributes. Clicking the button Correlate attributes performs this calculation; the
results are also depicted in the form of a matrix where the same scaling and coloring conventions
apply.
3.5
Interactive Weights
3.5.1
Introduction
In 3.7.4, we give a more detailed account of the methodology of ranking, that is: the aggregation of
ranking attribute values in order to come up with global recommendations of which item is ’best’.
For now we give an introduction that is more down-to-earth, but that gives a quick-and-dirty
introduction of some of the essentials.
Ranking is done with the purpose to find ’the best’ suited item from the repository, or to distinguish ’good’ items from ’bad’ items. What constitutes a ’good’ item, however, depends on the
relative importance of the various ranking attributes (the weight of the ranking attributes). It is
possible that we have a precise intuition what these weights should be; in most cases, however,
our intuition with respect to ranking attribute weights is not that sharp, and we would like to
explore the consequences of shifting the relative weights of some ranking attributes. This asks
for an interactive, direct-manipulation based interaction rather than a more rigid, quantitative
or algorithmic approach. Such a direct-manipulation based approach is offered in the Interactive
Weights form.
3.5.2
Manual
The controls of the Interactive Weights form consist of a number of sliders; one slider for every
ranking attribute. The range of every slider is the interval between 0 and 100; 0 means completely
unimportant; 100 means maximally important. Any distribution of values is allowed that sums up
to 100: shifting one slider up will automatically move all other sliders down, and vice versa. For
every distribution of ranking weights, as set by the sliders, the total scores are computed according
to formula
Sj =
X
Wi Sij
i
, where Wi is the weight for ranking attribute i; Sij is the attribute score of item j for ranking attribute i, and Sj is the total score for item j. We will explain later how Si and Sij are represented
in Assist; for now we only have to know that Wi are the numbers as set by the sliders. After
calculating the total scores, rows in the Data Grid are colored accordingly. That means: ’better’
items receive a color that is ’greener’ and ’worse’ items receive a color that is ’redder’. The calculation of resulting item scores from the individual ranking attribute scores is called aggregation.
Optionally (depending on settings in Preferences, see 3.14), after aggregation the rows are sorted
from poor (top) to good (bottom) items - according to the current setting of the ranking attribute
weights Wi . Since updating the Sj , sorting and re-rendering the table takes some time, the image
is refreshed only after each update of one of the sliders; the sliders can be moved continuously,
but not every change will result in a re-rendered image. Within one second, however, the most
recent status will be be made visible. Figure 3.5 gives a screen shot of the Interactive Weights
34
Figure 3.5: With the Interactive Weights form, the user can interactively control the weights of
various ranking attributes by dragging sliders)
tool and the colored column headers of the associated ranking attributes in the Data Grid in the
background.
The following controls are available in the Interactive Weights tool.
sliders
The only controls of the Interactive Weights form are the sliders to adjust the ranking attribute
weights; the number of sliders is equal to the current number of ranking attributes; every slider is
labeled with the name of the corresponding ranking attribute.
3.6
3.6.1
Inspire
Introduction
The classifiers and classifier values form Assist’s ontology. On the basis of this ontology, Assist
can do suggestions for new ideas. Four different approaches have been implemented to generate
new ideas:
Substitution : take an item, and replace a classifier value for some classifier by another (random)
value;
Combination : invite the user to think about the combination of two random items, where
Assist will make sure that one of the two items is not a special case of the other; for
instance, the suggestion ’combine a hammer with a tool’ will not be made, since a hammer
is a special kind of tool;
Invention : an item which has multiple values for one or more of its classifiers is called an abstract
item. Abstract items can be instantiated by less abstract or concrete items. As follows: an
abstract item A is instantiated by an item B (for instance: a ’tool’ is instantiated by a
3.6. INSPIRE
35
’hammer’) if the values for any classifier in B are a subset of the values for that classifier in
A. B either can be a concrete item, or an item that is less abstract than A. The interpretation
of ’abstract’ in Assist is, that an abstract item represents a heterogenous class of items.
Item A is less abstract than item B is the class represented by A is included in the class
represented by B. Whether or not an item is fully concrete - that is, its associated class
contains exactly one distinct item, is impossible to assess. Indeed, for an item with unique
values for all classifiers, it is always possible that in the future a further classifier will be
added that has multiple values - making this item abstract. So the qualification ’concrete’
is always a provisional qualification, to be overruled if we know more about the item. An
invention is the instantiation of an abstract item into a less abstract item that did not exist
before in the ontology. Notice that this concrete item is only defined implicitly in terms of its
classifiers. Whether the suggested series of classifier values for the classifiers makes sense is a
matter of interpretation; this, of course, needs to be done by the user. It is very well possible
that an ’invention’ is done by Assist this is physically infeasible, or completely implausible.
But even then it might trigger human creativity to think of something innovative;
Improvement : Assist has information about the adequateness of the represented items. An
improvement of an item is a version of that item that performs better in at least one ranking
attribute - although it might perform worse in terms of other ranking attributes. (Notice:
if an item A performs better in all ranking attributes than B, we say that A dominates
B. The notion of domination will be important when we introduce the notion of Paretooptimality. The improvement-suggestion works in such a way that the user is presented two
random items where one is significantly below average in some ranking attribute and the
other is significantly better; the user is invited to think of a version of the first item that
takes advantage of some aspect of the second item. Again, whether or not this is practically
feasible is of course impossible to assess for Assist.
3.6.2
Auto-ranking
Assist implements a heuristic method to assign values to ranking attributes of an item on the
basis of the classifier values. This is based on the notion of metric. A metric is a way to assign a
distance to pairs of items. ’Distance’ is a numerical quantity, attributed to a pair of items. The
intuition of distance is, that is should tell if items are far apart. Indeed, items who have the same
set of values for all classifiers cannot be distinguished; they are identical as far as the ontology is
concerned (even though they might have different names: the Morning Star is the same object as
the Evening Star, because they have the same bundle of attributes, and every attribute takes the
same values). We can use the number of classifiers in which two items differ as a simple (albeit
naive) measure for their distance. This distance is called the Hamming distance. 2 . The Hamming
distance was originally defined for binary strings of equal length, as the number of bits in which
the two strings are different. So ’110011’ and ’111111’ have Hamming distance 2. In Assist we use
a distance that is derived from the classifiers: classifiers in which two items are different contribute
to the distance of these items.
Once we know the distance (in the ontology) between all pairs of items, we can use this distance
to predict the result of ranking. Indeed, two items that have distance 0 should be identical in
ranking. The smaller the distance between two items, the more similar their ranking values should
be. This leads to the following idea: suppose we have a collection of items, Ti , i=1,2,3,..., having
item-attribute scores Sij for a particular attribute j . Next there is a further item, X, with
(ontological) distances Di to each of the items Ti . Then it is a reasonable prediction to say that
2 Assist
uses a slightly different for of the Hamming distance: when two items are different in classifier C, the
contribution to their distance is not just 1, but 1 over the number of values that C can take. The intuition here is,
that a classifier has less importance to distinguish classifiers when it has more values.
36
the ranking attribute value for item X is given by
Sij
Di
1
i Di
P
SX;j = Pi
.
This is the so-called Shepard interpolation formula 3 ; other, more advanced formulas could be used
as well.
One interpretation of this auto-ranking algorithm is: assuming that the knowledge as represented
by the classifiers is everything we know about the items, then the ranking value as computed by
the auto-rank feature is the best estimate for for the value for any of its ranking attributes.
Auto ranking is used in the process of doing suggestions in two ways.
First, we can have the suggestions be selected from a pool of suggestions: in that case, Assist
first calculates some 30 random possible suggestions, and for all these suggestions it computes
the auto-ranking algorithm. The one with the best total ranking score is presented to the user.
This feature is enabled by checking the check box ’use weights’ in the lower right corner of the
inspire-frame.
Second, once we have decided that we want to add an item in the case of a Substitution or an
Invention, Assist has full knowledge of all the classifier values of the new item. In that case it
calculates a first guess for the ranking attribute values of this new items using auto-ranking; the
resulting values are substituted in the Data Grid when the new item is entered.
3.6.3
Manual
The inspire form is shown in figure 3.6.
The form consists of roughly three parts. The top part consists of the four buttons that can
produce the four types of suggestions. The actual suggestion is written in the middle part of the
form. The lower most part allows the user to put a new item, in the case the suggestion has
inspired him/her to do so.
In case the user decides to add a new item as a result of a suggestion, and the suggestion was
either a combination or an invention, Assist has full knowledge of all classifier values for the new
item; the item will be added to the Data Grid with all classifiers fully filled in. In the other two
cases, the classifier cells will be left open: Assist has no way to find out what the combination or
the improvement has yielded.
In order to add an item, its name must be typed in the appearing text box. The same regulations
to valid item names appear as when entering an item in the Data Grid by means of the ’Add Row’
button.
For all four the suggestion methods, it is possible that Assists can not come up with a valid
suggestion. There can be various reasons for this to happen; for instance, for an invention it
is necessary that the actual row is an abstract item. In case Assist fails in coming up with a
suggestion, it gives a comprehensible warning with the cause of failure.
The following buttons can be used for the various forms of inspiration.
Substitution
Ask for a suggestion on the basis of substitution.
Combination
3 In this form, the interpolation is singular for D is 0. In that case, however, S
i
X;j = Sij - which corresponds to
our intuition.
3.6. INSPIRE
37
Figure 3.6: The Inspire form. In this case, the user had clicked the ’invention’ button. The
produced suggestion is an instantiation of an abstract item where Assist suggests values for all
classifiers that are not unique.
Ask for a suggestion on the basis of combination.
Invention
Ask for a suggestion on the basis of invention.
Invention
Ask for a suggestion on the basis of invention.
Use weights
When this check box is selected, the request for a substitution or invention is based on an internal
pre-selection of suggestions, using the auto-ranking algorithm.
Wild substitute
When doing suggestions for a substitution, the values for classifiers are normally taken from the
range of values that occur in the current Assist ontology. However, we can choose to take values
from a wider range. By clicking the check box ’wild substitute’, all possible values for the
occurring classifiers as they occur in the folk ontology are considered. This gives a much more
’wilder’ range of possibilities - hence the title of the check box.
When this check box is selected, the request for a substitution or invention is based on an internal
pre-selection of suggestions, using the auto-ranking algorithm.
Add new item
When a suggestion is given, the button ’Add new item’ becomes visible. If the user thinks of a
new item (as a result of the suggestion, or spontaneously ...) a new item can be entered without
leaving the inspire tool by clicking on this button. Next, the name of the new item can be entered,
and the new item appears in the Data Grid.
38
3.7
3.7.1
Relations
Relations: a fundamental notion in Assist
At first sight, it may seem that Assist is a simple spreadsheet or database, organized in the form
of one single table with items as rows and classifiers or ranking attributes as columns. Such a
table structure is useful to administrate a list of ideas (or any list of things that may need to be
distinguished and/or ranked in some sense), but it does little more than book keeping. Assist’s
main functionality, however, is hidden in the internal data structures of Assist. Both of its
distinguishing features (viz. maintaining the ontology that allows doing inventions and exploring
variations, and ranking these according to various criteria) rely on a single formal notion.
This is the notion of partial ordering.
3.7.2
Partial ordering, transitivity and a-cyclic graphs
One way to view a partial ordering, is to interpret it as a collection of arrows over a set of points.
Every point represents an item; an arrow can have two distinct interpretations:
inclusion or the ’is-a’-relation, for instance an arrow can exist pointing from ’hammer’ to ’tool’,
or from ’apple’ to’fruit’;
comparison or the ’is inferior to ... with respect to a given ranking attribute’-relation, for instance an arrow can exist pointing from ’motorcycle’ to ’bicycle’ where the ranking attribute
is ’CO2 emission’.
A collection of points and arrows is called a directed graph. Even if there are no arrows (yet), the
collection of points forms a graph; also when there are no points at all we can speak of an (empty)
graph.
In the case of partial ordering, we adopt two further conventions that are compatible with the
inclusion and the comparison-interpretations.
transitivity : if there is an arrow from A to B and a second arrow from B to C, we can deduce
that an arrow is possible between A and C. The latter arrow is redundant; this means that it
gives no independent new information to the existing set of arrows. Redundant arrows can be
removed. An example of redundancy in the inclusion-interpretation is: a pneumatic hammer
is a hammer; a hammer is a tool; hence a pneumatic hammer is a tool. The last proposition
follows by transitivity; it is redundant. (Notice that none of the other two propositions is
redundant!). An example of redundancy in the comparison-interpretation is: a motorcycle
is inferior to a bicycle; an aircraft is inferior to a motorcycle; hence an aircraft is inferior
to a bicycle (all with respect to the same ranking attribute: CO2 emission). Again the
last proposition is redundant. Since they carry no independent information, all redundant
relations are automatically removed in Assist;
absence of cycles : both interpretations forbid that a sequence of arrows exist where the last
arrow points to the item where the first arrow starts. There is a subtlety here: if the
inclusion-interpretation is admitted to hold between identical items (which can be justified,
indeed: a hammer is a hammer), a cycle is not problematic. Similar, if ’is inferior to’ is
interpreted in a weak sense as ’is not better than’, identical values for a ranking attribute
could give rise to a cycle. To avoid numerous dubious cases, however, we adopt a strict
interpretation and forbid any cycles in Assist.
Since partial orders underly two fundamental functions of Assist, there is a single generic methodology to manage partial orderings. Despite that the partial orderings can mean two very different
3.7. RELATIONS
39
Figure 3.7: The Relations form showing the relationships as a partial ordering for the ranking
attribute ’price’. The user has clicked on the tail (=left clickable spot) of the item-icon ’bread
knife’. The arrows connecting this item to the heads of the items ’hand saw’ and ’hammer’ are
colored red to better show the connectivity. Apparently, ’bread knife’ is better than ’hand saw’
and better than ’hammer’ with respect to ’price’. Further, the heads of a number of item-icons
are colored green (for instance, ’sand paper’, ’screwdriver’, ’axe’ and others), indicated that an
arrow connecting the tail of ’bread knife’ to any of these heads is permitted.
things with respect to items, the handling of points and arrows is fully identical. This is handled in
the Relations tool. In figure 3.7 a screenshot is depicted of this tool, where the current relationship
a comparison-relation for the ranking attribute ’price’.
When clicking on the Relations button right next to the Data Grid, the Relations-form appears.
Which relation is shown depends on the currently actual column. If this column is a ranking
attribute, the ranking attribute is taken to be the relation for which the partial ordering is shown:
in that case, it is a comparison-relationship. In all other cases, it is the inclusion-relationship.
Whichever of the two cases applies, the graph is shown as a collection of item-icons. Every itemicon represents one item. The item-icon is a small dragable rectangle. The name of the item is
written underneath the rectangle. An item icon contains two clickable spots, one to the left and
one to the right. These two are the places to connect arrows. The right clickable spot is called
the head of the item icon, the left clickable spot is called the tail. Arrows always run from left to
right, from the head of the leftmost item-icon to the tail of the rightmost item-icon.
In the case of an arrow, the left item is called the inferior , and the arrow’s tail is connected to the
head of the inferior item. The right item is called the superior , and the arrow’s head is connected
to the tail of the superior item.
40
In the case of an inclusion-relationship, the superior is the abstracter of the two items. So, in the
case of an arrow pointing from ’hammer’ to ’tool’, ’hammer’ is the inferior item and ’tool’ is the
superior item.
In the case of a comparison-relationship, the superior is the superior of the two items. So, in case
of an arrow pointing from ’motorcycle’ to ’bicycle’, ’motorcycle’ is the inferior item and ’bicycle’
is the superior item, when the comparison is ’is inferior with respect to CO2 emission’.
Item icons can be freely moved (dragged) over the Relations-form, but the left-right ordering of
items that are connected by arrows is controlled by Assist. In particular in the case of many
items it is recommendable to attempt an arrangement of item-icons where few arrows cross. (In
general, however, this is not always possible.)
To facilitate building, altering and inspecting partial orderings, Assist has a number of provisions
that apply irrespective of whether the relations are inclusions or comparisons.
As follows:
• When a head or tail of an item-icon is clicked, all connected arrows are colored red. This
helps understanding the connectivity of the graph in case of many, possibly crossing arrows;
• When a head or tail of an item-icon is clicked, Assist does an analysis of all possible new
arrows that could be formed starting in this item. ’Possible’ here means the following:
– the relation doesn’t exist yet
– adding the relation will not cause any cycles;
– in case of an inclusion relation: adding the relation will not conflict with any current
classifier values. For instance, item A with values x, y, z for classifier C can never be
the inferior item for an item B with values x, z for that same classifier;
– in case of an inclusion relation: adding the relation will not conflict with any currently
existing comparison relations. For instance: suppose for items A and B, we have that
A is inferior (for some ranking attribute) than B. In that case, we cannot make A to
include B. (The precise details of the connection between inclusion and comparison
will be explained below);
– in case of a comparison relation: adding the relation will not conflict with any currently
existing inclusion relations. For instance: suppose for items A and B, we have that A is
a special case of B. In that case, we cannot make A inferior (for some ranking attribute)
to B. (The precise details of the connection between inclusion and comparison will be
explained below);
All admitted tails or heads are colored green: these form suitable connection points for an
new arrow.
• In order to remove an arrow, its both ends simply have to be clicked again. To facilitate
finding the existing arrows connected to some given head or tail spot, the partner tail or
head spots are colored white (notice: these are on the other end of a red arrow). Clicking
on a white spot will erase the connecting arrow.
Despite these provisions, it is possible that managing the collection of arrows gives rise to an
incomprehensible jumble. This may also happen because arrows can not only result from directly
drawing them into the Relations-tool; also as a result of answering Questionnaire-questions (see
3.9), arrows are created. In case the user should decide to remove all arrows and start anew,
(s)he can click on the delete all button in the right upper corner of the Relations-form. This will
remove only the relations that are managed in the actual Relation-form; all other relations are
left untouched.
41
3.7. RELATIONS
item
Kanoo
Jeep
Boeing
Boat
Car
Aircraft
environment
water
land
air
water
land
air
price (in Euros)
102 . . . 5 × 103
103 . . . 5 × 104
106 . . . 107
102 . . . 107
5 × 102 . . . 5 × 105
104 . . . 107
Table 3.1: A miniature ontology of vehicles
3.7.3
Partial ordering, set-inclusion and ontology
An essential feature of the Assist system is its ability to deal with set-valued classifiers. For any
item, a classifier can either have no value (indicating that the classifier does not apply to that
item); a single value (indicating that perhaps the item is a single thing with a single unique value
for that classifier); or a set of values, indicating that the item is an abstract item: a collection of
things, with at least one distinct thing for each different value.
This allows to represent the notion of instantiation, or is-a relations in the Assist ontology.
As explained above, the is-a relationship is an example of a partial ordering.
Is-a relations occur in two different flavors, to be called intentional is-a relations and extensional
is-a relations.
Intentional relations
An intentional is-a relation between a parent item P and a child item C expresses the intuition that
C is a specialization of P . This corresponds to the notion of inheritance in object-orientation. We
say that a chair is a specialization of the class ’furniture’, and a ’Rietveld chair’ is a specialization
of the class ’chair’, and the particular Rietveld chair that is on display in the Kröller-Müller
museum in the Netherlands is a specialization of the class of all Rietveld chairs. The KröllerMüller class is a peculiar example, since it contains only a single element; such a class is called
a singleton. This notion of intentional specialization can be expressed without any reference to
classifiers or their (sets of) value(s). Intentional specialization can imply that a child has multiple
parents: not only is the Kröller-Müller Rietveld chair an instantiation of the class ’Rietveld chair’,
it is also an instantiation of the class ’pieces of art of the Kröller-Müller museum’; this class is a
specialization of the class ’assets of Dutch Musea’, et cetera. This is called multiple inheritance
in object orientation.
Extensional relations
An extensional is-a relation between a parent item P and a child item C, to the contrary, can
only be defined on the basis of inspecting classifiers and their values for P and C. There are
some options for this definition, though. To explain this, we introduce an example. We consider
the following classes: Kanoo, Jeep, and Boeing as specializations of the classes Boat, Car, and
Aircraft, respectively. Further, we have two classifiers, ’environment’, with values ’water’, ’land’
and ’air’, and ’price’ with values amounts of money between hundred and ten million Euros.
Intuitively, the miniature ontology from table 3.1 would seem appropriate.
We conclude that for the class Kanoo the set of values for each classifier is a subset of the values
for the same classifier for the class Boat. If we define the extensional is-a relation as C is-a P by
’for every classifier, the set of values in C is a subset of those in P ’, we conclude that Kanoo is-a
42
item
Hover craft
Amphibian vehicle
Bat car
environment
water; air
land; water
air; land
Table 3.2: A miniature ontology of hybrid vehicles
Boat in extensional sense, and similar Jeep is-a Car, and Boeing is-a Aircraft. So far so good:
this corresponds to our intuition.
Next we introduce as a classifier ’materialOfOars’, which for a kanoo could take values such as
’wood’, ’metal’, or ’carbon fibre’. Now we should think what to do with the classifier ’materialOfOars’ when applied to Car. Cars don’t have oars, so there is no meaningful value for this
classifier; the most obvious thing is to assign the empty set. For the class Boat this is more subtle,
though: some boats do have oars (like kanoos and rowing boats); others don’t (like speed boats).
If we would choose to leave the set of values for ’materialOfOars’ empty for the class Boat, we
would loose the intuition that the set of values for a child is a subset of the set of values for the
parent. Therefore, it is intuitive to assign the entire set of values, {wood, metal, carbonFibre} to
the classifier ’materialOfOars’ for the class Boat. We will call this the ’liberal’ interpretation of
classifiers. It states that the set of values for a classifier for a parent class P is the union of the
sets of values for that classifier of all (extensional) children C of P . An immediate consequence,
though, is that for some children of P , such a classifier might have an empty set of values (for
instance, the classifier ’materialOfOars’ for the item ’speed boats’). The liberal interpretation
contrasts with the ’restricted’ interpretation, where a classifier takes the set of values that must
hold for all individuals in a class. In the restricted interpretation, ’materialOfOars’ for a particular (type of) kanoo(s), characterized by one particular material of oars, will take the value of
precisely that material; for all other classes, the value of ’materialOfOars’ is empty. In that case,
in particular, the classifier ’materialOfOars’ for the item ’boat’ will be empty.
Since the restricted interpretation gives relatively many instances of classes P with empty-valued
classifiers (which don’t give any information except that extensional children of P don’t have
any shared values for the classifier(s) considered), we adopt for Assist the liberal interpretation.
Apart from the consequence that some children of a parent with a non-empty classifier can have
an empty set of values for such a classifier, it has at least one other curious consequence, though.
Consider three additional classes: Hover craft, Amphibian vehicle and Batcar4 . The values
for the classifier ’environment’ are as listed in table 3.2. Restricting ourselves to the classifier
’environment’, we see that both Kanoo and Boeing are extensional specializations of Hover craft.
Even the ’more abstract’ classes of Boat and Aircraft are extensional specializations of Hover
craft. Similar, we have:
Jeep is-a Amphibian vehicle;
Kanoo is-a Amphibian vehicle;
Car is-a Amphibian vehicle;
Boat is-a Amphibian vehicle;
Boeing is-a Bat car;
Jeep is-a Bat car;
Aircraft is-a Bat car;
Car is-a Bat car,
4 Batman is an imaginary comic book superhero, featuring in several Hollywood movies. Among his many
spectacular tools and vehicles, there is an automobile with flying capabilities: the Batcar.
43
3.7. RELATIONS
item
Kanoo
Jeep
Boeing
Hover craft
Amphibian vehicle
Bat car
Boat
Car
Aircraft
environment
water
land
air
water; air
land; water
air; land
water; air; land
land; water; air
air; land; water
Table 3.3: A miniature ontology of vehicles where both hybrid, ’regular’ and generic classes occur.
all in extensional sense.
Even more peculiar: if we want to save the intuition that Hover craft is-a Boat (in extensional
sense), and similar ’obvious’ parent-child relations for the other hybrid vehicles, we are enforced
to assign all three values ’water’, ’land’ and ’air’ to the classifier ’environment’ for all three ’grand
parent’ classes, Boat, Car and Aircraft, as in table 3.3. In other words: if the ontology needs
to include both ’regular’ and ’hybrid’ vehicles, the (extensional) distinction on the basis of the
classifier ’environment’ no longer exists.
If it may seem strange that, in the liberal interpretation, classes Boat, Car and Aircraft cannot be
distinguished (at least: they are indistinguishable with respect to the classifier ’environment’), we
must remember that the extensional definition of the is-a relation is merely a formal construction;
in the absence of hybrid classes, it usually gives a reasonable to good correspondence to our
(intentional) intuition.
Intentional vs. extensional relations
In daily discourse, we use the clause ’is-a’ without giving much thought about whether this is an
intentional or an extensional statement. Apparently, there must be quite a large similarity between
the two. Sometimes we will mean the intentional version, sometimes we mean the extensional
version. The same is true when using Assist. When we set values for classifiers in the Data Grid,
we indirectly define extensional is-a relations; when we declare that an item is to be regarded
as an intentional parent of an other item in the Relations tool, we state an intentional version.
Therefore it must be possible to convert one into the other - or at least: to adjust one of the two
in accordance with the other.
We recollect the definition of intentional is-a relation: in order for item C to have an is-a relation
with item P (C is-a P ), the set of values in C must be a sub set of the set of values in P .
Maintaining consistency between intentional and extensional relations over a set of items is a
subtle and sometimes counter-intuitive issue. For a better understanding, we address this issue in
the next sub-section.
Consistency and propagation
We have seen that all intentional relations eventually originate from the user, expressing that some
item a is a special case of another item b; extensional is-a relations originate from inspecting the
sets of values for classifiers, and see if by chance the definition of the extensional ’is-a’-relation
holds. In principle, the two sets of relations develop independently of each other, and we have
to actively do something to the data to ensure consistency. This can be done, altogether, in four
44
different ways.
1. from intentional to extensional, bottom-up;
2. from intentional to extensional, top-down;
3. from extensional to intentional, bottom-up;
4. from extensional to intentional, top-down;
In Assist, propagation is only done automatically from intentional to extensional, both bottomup and top-down. The bottom-up route will only enlarge sets of classifier values; the top-down
route will only reduce sets of classifier values.
We give some examples: assume we have the intentional is-a relation between ’hammer’ and
’pneumatic hammer’, and a classifier ’motorized’. Initially, ’motorized’ for ’hammer’ takes the
value ’no’. Next we decide that a pneumatic hammer is motorized, so we will fill in the value ’yes’
for the ’motorized’ classifier for the pneumatic hammer. Assist will then automatically propagate
the value ’yes’ to ’hammer’, resulting in the new value ’yes,no’.
Conversely, if the intentional is-a relation between ’pneumatic hammer’ and ’hammer’ does not
(yet) exist, and we fill in the values ’yes’ and ’no’ respectively, no propagation will occur. If we
should decide next to add the intentional is-a relationship, this is refused by Assist on the grounds
that ’hammer cannot be a parent for pneumatic hammer because the extensional is-a relationship
is not fulfilled for the classifier ’motorized’.
As a last example, suppose we have again the intentional is-a relationship holding between ’hammer’ and ’pneumatic hammer’, and ’hammer’ has value ’yes,no’ filled in for ’motorized’. If we edit
this value and replace it by ’no’, the reduction of this set propagates down and the result is that
the value for ’pneumatic hammer’ becomes empty.
Although automatic propagation only takes place from intentional to extensional relationships,
extensional relationships do play a role when new intentional relationships are about to be added.
Indeed, as explained in section 3.7.2, when we try to add a new is-a-relationship, Assist first checks
if this relationship is allowed. ’Allowed’ means, among other things, that the new (intentional)
is-a-relationship does not conflict with existing extensional is-a-relationships.
Although the automatic propagation normally corresponds exactly to the intuition, there can be
cases when one would like to override the process (for instance with hybrids, such as the hover
craft, the Batcar, or the amphibean vehicle as explained above). In the Preference-tool (see ??),
there is a checkbox that serves to switch the automatic propagation of classifier values according
to intentional is-a relationships on or off.
3.7.4
Partial ordering, comparison and ranking in Assist
A partial ordering is a mathematical concept that lies closely to many day-to-day intuitions.
Comparisons, for instance, usually involve partial orderings. If we say that pineapple is sweeter
than lemon, and similarly that peach is sweeter than lemon, few people will disagree. We cannot
say, however, which of pineapple or peach is sweeter. Apparently, the relation ’is sweeter than’
applies to some pairs of fruits, but not to all. An ordering that applies to selected pairs of a set
is called a partial ordering. Virtually all comparative relationships are partial orderings. There
are relatively few cases of relationships that apply to all pairs of individuals in a set. Such
relationships are called full ordering. An example is ’is heavier than’: everything with a mass that
can be assessed can be compared with respect to weight to everything else, and with sufficient
measurement accuracy it is always possible to state that one is heavier than the other. That is
because ’is heavier than’ involves an ordinal scale. In the present case this scale can even be
associated to numbers (1 kg, 2 kg, 3 kg, 4.2543453 kg, et cetera).
3.7. RELATIONS
45
A scale that is not ordinal is called nominal . An example of a nominal scale is the answer to the
question ’what country are you from’ (with answers Belgium, Albania, ...). The names of countries
can, of course, be fully ordered by means of a lexicographical ordering beginning in Afghanistan
and ending in Zimbabwe.
It is tempting to map fully ordinal scales to numbers - in particular, natural numbers, since natural
numbers are a familiar example of a fully ordered scale. A famous counterexample is Mohs’ scale
for the harness of minerals: a material A is harder than a material B if B is damaged (scratched)
by A when brought into rubbing contact. The mapping to natural numbers in this case would be
misleading: for numbers we can assign a meaning to the difference between items. For instance,
the difference between 4 and 7 equals the difference between 5 and 8. This does not have to
apply to items in the Mohs scale, however. It can be meaningless to talk about the ’difference
in hardness’ between the 4th and the 7th material in Mohs’ scale. It is even meaningless to
say that there are precisely two materials in between: it is very well possible that tomorrow an
exotic material is discovered with a hardness in between number 4 and number 7. This causes
the mapping to natural numbers to be overthrown, whereas all relations ’is harder than’ stay in
place. A scale that can be mapped to (natural) numbers is a quantitative scale. Mohs scale is
an (fully) ordinal scale that is not quantitative. A second important example of an ordinal scale
that is not a quantitative scale is the range of exam results A,B, ... F used in American school
systems. There is no statement of the magnitude of difference between subsequent marks, so it is
impossible to say what is the ’average’ between A and F. In other school systems, digits are used
(e.g., 10 ... 1). In that case, it is arithmetically possible to define that the average between 10 and
5 is 7.5 - but this implicitly assumes that the difference between 5 and 7.5 equals the difference
between 7.5 and 10. In most cases of classroom assessment, this last requirement cannot readily
be assured.
We can summarize:
• scales can be nominal or ordinal;
• ordinal scales can be partial (e.g., sweetness in the pineapple - peach - lemon example) or
fully ordinal
• fully ordinal scales can be non-quantitative (e.g., Mohs scale) or quantitative
• a quantitative scale allows mapping to numbers, and it implies that differences are meaningful. But ratios don’t need to be meaningful. For instance, the Kelvin temperature scale
has a meaningful notion of ratio. Indeed, 10 K is twice as warm as 5 K in an independent,
physical sense, whereas 10 Centigrade is not in any meaningful way twice as warm as 5
Centigrade. This introduces the notions of difference scales and ratio scales
When we get back to Assist, it is obvious that the above discussion about partial ordering
immediately relates to ranking items. Indeed, familiar ranking methods map the adequateness
of items (with respect to some criterium) to numbers; next assign some (numerical) notion of
importance to each ranking attribute, and next compute a weighted-sum ranking.
Weighted sum-ranking was mentioned before in section 3.5. As we observed there, it assumes that
each of the quality attributes i has a numerical weight Wi (which must be an element of some
ratio scale for the following operations to make sense). If the score of item j on attribute i is Sij
(again an element of a ratio scale), the total score of item j is defined as
Sj =
X
Wi Sij .
i
To distinct them from total scores, the values Sij will be called item-attribute scores or ranking
attribute values. It is tempting to see the item with the highest total score as the ”best”. This is
a bit naive, though, for several reasons.
46
1. as illustrated with the pineapple - peach - lemon example, the opinions that people have
about certain quality features of items is very often a partial ordering. That means: it is
no full ordering, and since it is no full ordering it is impossible to associate it with any
quantitative scale - and in particular not with a ratio scale;
2. if - despite the above argument - we insist to associate the item-attribute scores and the
weights to numbers, it is somewhat arbitrary to have precise numerical weights for quality attributes. This suggests much more precision than reasonably can be assumed. Suppose that profitability is more important than safety, should we then set Wsaf ety = 40,
Wprof itability = 45, or Wsaf ety = 10, Wprof itability = 90? A similar problem applies to the
item-attribute scores;
3. even if we disregard the formal objection that item attribute scores in most cases are not on
a quantitative scales, we will encounter the practical problem that most attributes are not
readily expressed as numbers: perhaps, profitability (which relates to an amount of money)
can be quantified more or less accurately on a numerical scale, but safety is much harder to
cast in the form of a number.
Assist, unlike most decision support systems that assist in selecting among items on the basis
of criteria, therefore does not use elements from a quantitative scale to represent user’s opinions
about the relative adequateness of items. Instead, these opinions are represented as collections of
partial orderings.
Unfortunately, as can be concluded from Arrow’s theorem5 , if we have nothing more than a set
of (partial) orderings among the collection of alternative items, each ordering representing the
state of affairs with respect to one ranking attribute, it is not possible to decide upon a resulting
ordering (either partial or total). In other words, it is fine to represent the individual opinions in
the form of pairwise comparisons, avoiding the use of any numerical operations, but that gives no
support to the user when it comes to making the final decision.
Since Assist is intended to be used in an interactive or collaborative context, we adopt a policy
that is somewhere in between formally correct (i.e., not using numerical representations where
this is not allowed) and practical (i.e., giving assistance to users that is comprehensible and may
support intuition).
In order to support intuition, we must convey two aspects of the comparisons:
• for a given ranking attribute, one item can be inferior to another. We do this by adopting
the rank order of colors as they appear in the rainbow; the convention is that red is bad and
green is good. Since the hues in the rainbow form a perceptually fully ordered scale, we can
visually observe for two rank attribute values which of the two is the ’redder’ and which is
the ’greener’. From this we can conclude which is the worse and which is the better;
• for two items A and B, where A is more abstract than B (so B is an instantiation of A), we
have that the coloring must reflect this inclusion relation. Suppose that there would be a
third item, C, that is also an instantiation of A. Let C be better (for some ranking attribute)
than B. This means that the color for that ranking attribute for C is greener than the color
for B. But the color for A can not be redder than the color of C, and it cannot be greener
than the color for B. So it must have a color that encompasses both the hue of B and the
hue of C. Now for colors, this behavior is nicely reflected into the perceptual property of
saturation. Indeed, less saturated colors are less clearly distinguishable, matching with the
intuition that rank attribute values for more abstract items can take a larger range of values.
So the mapping of rank attribute values to the hues and saturation of colors introduces a single
universal scale that contains two full orders at once - and these both orders can be one-to-one
mapped to the comparison ordering and the is-a ordering.
5 http
: //en.wikipedia.org/wiki/Arrow%27s impossibility theorem
3.7. RELATIONS
47
We associate being more or less saturated with being less or more abstract. But it is a small
jump from ’abstract’ to ’uncertain’. Indeed, when we know less about an item (that is, there
are more admitted values for its classifiers), we could say either that it is more abstract, or that
its adequateness is less precisely assessable. So the saturation on the one hand serves to distinct
more abstract items from less abstract items; on the other hand it serves to encode our feeling of
certainty for the rank attribute value for a certain item.
One could say that an upper bound on the saturation (for some ranking attribute) comes from
the abstractness (or rather: the concreteness) of an item; but even if an item is not very abstract
at all (for instance, because all its classifiers have unique values, and/or it has no intentional
children) we may feel uncertain about its adequateness for some ranking attribute; in that case,
its saturation can be low.
We note in passing that there is a minimum saturation: the ’color’ white is neither reddish nor
greenish: it has no preference towards ’bad’ or ’good’ according to our hue scale. It is therefore
a natural choice to represent the totally unknown, maximally uncertain (or maximally abstract)
rank attribute value by white.
At any time, Assist assigns colors to ranking attribute values, thereby obeying both orders (the
comparison order and the inclusion order). This means that, as soon as we add or delete a
relation (either a comparison-relation or an inclusion-relation), the colors are re-calculated and
updated. This color assignment, however, is not unique. Even though Assists internal algorithm
is deterministic - which means that it produces the same outcome every time it calculates color
assignment for a given set of partial orderings, we may wish to express our feeling that a particular
ranking attribute value should be redder or greener. We may also decide to make a saturation
larger or smaller if we feel we are more or less certain about a ranking attribute value.
As we will see in a minute, there are two ways to do so (one using sliders, see 3.8; the other one using
the quick ranking device, see 3.14). Whenever we do so, Assist ensures that all partial ordering
relationships are preserved by adjusting other ranking attribute values whenever necessary in a
minimal way, that is: it applies minimal adjustments to ranking attributes to ensure that all
partial ordering relations are as they should be.
By means of the representation of ranking attribute values-as-colors, we have transformed the
(partial) ordering relations into concrete values on a 2-dimensional scale, and we have found a
way to make them visually assessable. We have not yet, however, explained how they can be
aggregated into a resulting conclusion. Indeed, the entire ranking process was part of the selection
of the ’best’ item, so we must find a way to combine all ranking attribute values into a single
ordering on items.
First we mention that, according to Arrow’s result, their is no algorithmic, non-arbitrary way to
do this. So we must keep in mind that any approach is, in some way or other, ’cheating’.
There are two cheating mechanisms built in in Assist.
The two methods for aggregating ranking attribute values, supported by Assist are:
• Pareto front-ranking;
• weighted sum-ranking.
Pareto front-ranking
In Pareto front-ranking, we distinguish dominated from non-dominated items. A dominated item
is an item for which another item exists that is better in all respects. For instance, suppose that
the criteria we want to use for ranking are profitability and safety, both on a 100 point scale.
An item with profitability = 50 and safety = 30 is dominated by an item with profitability = 60
48
and safety = 35. Such a dominated item should never be chosen, since there is at least one item
which is better in all respects. An item that is not dominated is called a non-dominated item; the
collection of non-dominated items is said to form the Pareto front of a collection of items. Pareto
front-ranking amounts to finding the Pareto front in a collection of items; those that are not on
the Pareto front can be discarded.
In Assist, the result of a Pareto calculation can be made visible by means of colors. In the
Preferences (see 3.14 we can choose to visualize the aggregation result as a Pareto-front. In that
case, item names are colored green if they are on the Pareto front; if not, they are colored red.
Weighted Sum-ranking
To explain weighted sum-ranking, we again mention the classical formula introduced before:
Sj =
X
Wi Sij .
i
When we introduced this formula in section 3.5, we did not explain how Sj and Sij were represented. Now we know that they are 2-dimensional quantities, encoding both the hue and saturation
of the colors that are assigned to ranking attribute values and item scores.
In order to calculate and add colors, however, we have to map them to values that allow addition
and multiplication. Obviously, this is where the ’cheating’ comes in. In Assist we cheat by
representing colors by numerical intervals. The range or width of the interval represents the
saturation: a narrow interval means a high saturation; a broad interval means low saturation.
The lower and upper bounds in the intervals are between 0 and 100 (which are merely arbitrary
bounds). Lower numbers mean ’redder’ colors, and higher numbers mean ’greener’ colors.
So [100, 100] is very saturated green; [0, 0] is very saturated red; [50, 50] is very saturated yellow;
[0, 100] is white (minimal saturation).
The formula
X
Wi Sij
Sj =
i
calculates Sj also as an interval. So the aggregation (= the calculation of all Sj ) produces a
collection of intervals, one for each item, where the weights Wi of the ranking attributes have been
taken into account.
Now we observe something peculiar when we compare operating on intervals with operating on
numbers. Indeed, an interval I1 is less than interval I2 only if the upper border of I1 is less than
the lower border of I2 . If the lower border of I1 is larger than the upper border of I2 we say that I1
is larger than I2 . In all other cases, the order of I1 and I2 is not determined. So the weight [10, 50]
is not less than [30, 70], even though its centroid (= the average of lower and upper bound) is less.
Both weights are equally uncertain. Calculating with weights and scores as intervals protects us
against hastily and non-substantiated conclusions: the total
P score Sj is only larger than an other
total score Sj′ if the involved intervals, used to compute i Wi Sij , are sufficiently narrow - that
is: if we are sufficiently certain about a sufficient number of item-attribute scores and attribute
weights.
In Assist, the result of a weighted sums calculation can be made visible by means of colors. In
the Preferences (see 3.14 we can choose to visualize the aggregation result as a weighted sums
calculation. In that case, item names are colored green if their item score is entirely larger than
the score of some other item. Item names are colored red if their item score is entirely less than
the score of some other item. If both conditions occur the item name is colored yellow; if non
applies it is colored white.
3.8. SLIDERS
49
Figure 3.8: The sliders tool for ranking attribute ’price’. Every slider corresponds to one item;
the interval representing the ranking attribute value can be adjusted by moving its lower value
and its upper value. When necessary to preserve all partial orderings, Assist will automatically
adjust the ranking attribute values of other items.
Comparing Pareto front ranking and Weighted Sum ranking
The advantage of Pareto front-based ranking is, that we don’t need the weights. With a different
set of weights, the same Pareto front will result. A disadvantage, though, is that the number of
non-dominated items can be prohibitively large, in particular if we have many attributes. Indeed,
the more ranking attributes, the more severe the restriction of domination. So the fewer items
will be dominated - that is, the fewer items will be not on the Pareto front.
The weighted sum-ranking method can produce arbitrarily few solutions (if all the interval widths
are close to 0, there will, in general, be only one ”best” solution - even though this may not mean
a lot), but it has more room for arbitrariness.
Assist has been designed such that the two methods can be easily interchanged, depending on
the characteristics of the present collection of items: this is done by adjusting the settings of the
appropriate check boxes in the Preference form (see 3.14).
3.8
3.8.1
Sliders
Introduction
Assists ranking mechanism hinges on collections of partial orderings that directly reflect the user’s
opinions about relative adequateness of items with respect to some ranking attribute. For any
given set of partial orderings, Assist calculates a default mapping to a set of intervals, that are
rendered as colors. The user may want to adjust this mapping, however. To this aim, for every
ranking attribute (=interval) a slider is given. The slider is labeled with the name of the ranking
attribute. There are two thumbs on the slider that can be moved independently by dragging with
the mouse; the thumb corresponding to the lower border can not be dragged to the right of the
50
thumb for the upper border.
After every adjustment of slider thumbs Assist checks if the adjustment causes other ranking
attribute values to be adjusted as well. There can be two reasons for this:
• the ranking attribute value for the chosen item i is involved in one or more comparison relationships. For instance, the user moves i’s upper bound to the right, whereas the ranking
attribute value for i must be lower than the value for some other item j. In that case the
lower bound of j is also moved to the right. But this in turn may cause other adjustments
(perhaps the upper bound of j must move to the right, and so on). This is called propagating
adjustments. Notice that, as a rule, intervals will get narrower as a consequence of propagating adjustments - to the extent where the lower and upper bounds coincide. In that case
it requires some effort to get access to the two thumbs independently: they overlap on the
screen;
• the item is involved in some inclusion relationship. As we discussed before, the interval for
any ranking attribute for item i is entirely enclosed within the interval for the same ranking
attribute for any item j that is more abstract than i. So again adjusting interval borders of
i can result in interval borders of other items to be changed.
In more complicated configurations, the two mechanism above can occur at the same time: for
instance if an abstract parent of some item is involved in some comparison relation with another
item. Assist takes care of the entire propagation automatically, doing minimal adjustments to
ensure that all ordering relations are preserved.
3.8.2
Manual
The Sliders-form, for the case where the actual column associates to a ranking attribute, looks as
in figure 3.8. Each of the sliders corresponds to one item; it gives access to the ranking attribute
associated to the actual column at the time of opening the form.
3.8.3
Sliders for the ’include’ relation
As with the Relations-form, the Sliders-form uses the convention that the actual relation is defined
by the currently actual column when the form is opened. For columns that are ranking attributes,
this results in a set of sliders for that ranking attribute. In case the column is not associated to a
ranking attribute, however, the situation is different.
The convention applies that, in case the actual column is not associated to a ranking attribute,
the shown sliders relate to the total item scores.
First, this gives a convenient alternative view to the total scores.
Second, it gives the possibility to adjust attribute weights in an alternative way. As follows.
Suppose that we have a number of items, and we can provide item-attribute scores for all these
items for all ranking attributes, but we find it difficult to give values to the attribute weights. If
we can give total scores for the items, however, Assist can attempt to calculate weights that are
compatible with these total scores - provided that a set of weights exists that is compatible with
the given item-attribute scores and total scores. This amounts to solving for the Wi from a set of
equations
Sj =
X
i
Wi Sij .
3.8. SLIDERS
51
Figure 3.9: The Sliders form when opened in a state where the actual column does not associate
to a ranking attribute. This gives access to the automatic estimation of attribute weights.
Since the set of items (=the set of j-s) is typically (much) larger than the set of attributes (=the set
of i-s), these equations can only be solved exactly in rare occasions. If the item-attribute scores are
sufficiently consistent, however, a so-called least-squares optimal solution will be generally quite
reasonable. Assist applies an iterative solution strategy to approximate such a least-squares
optimal solution. Automated calculation of weights in this manner is governed by the Sliders tool
in case it is opened in a state where the actual column does not associate to a ranking attribute.
We give the detailed operation for this functionality. It uses some additional controls, as depicted
in figure 3.9. We we explain their working below.
3.8.4
Manual
The form looks as depicted in figure 3.9. First, sliders can be adjusted at will; with every adjustment, Assist calculates a residue. This is a number, expressing the squared difference between
the total scores as set by the user, and the total scores as calculated with
Sj =
X
Wi Sij
i
for the current set of attribute weights Wi and the current set of ranking attribute values Sij . In
general, the more the user moves the sliders away from their initial position, the larger this residue
will be. The residue is written in a text field to the right of the sliders.
Obviously, when the residue is equal to 0, there is a perfect match between the item scores as set
by the user and those as calculated from the attribute weights.
By clicking the try button , Assist does an attempt to adjust the attribute weights in order to
make the residue smaller. It does so by moving all individual attribute weights a fixed amount in
both directions, recompute the residue, and compare the changes. If it turns out that in either
direction an improvement could be reached, it will preserve these new attribute weight values.
The fixed amount, used to move the attribute weights, can be adjusted by the slider stepsize.
52
Figure 3.10: The questionnaire form allows to engage in a dialogue where Assist gives propositions
that the user can react upon by saying ’agree’, ’disagree’ or ’no opinion’.
It is a good heuristic to start the process with large values for the stepsize; if no more improvement
of the residue can be reached, move to smaller values - until the residue is minimal.
As mentioned before, we must realize that for arbitrary setting of the total scores, there are
presumably no values for the attribute weights that produce a perfect match (that is, residue=0).
Therefore, the user may decide to go back to the initial values of the attribute weights by clicking
the button reset original.
Alternatively, it is possible to re-start the entire search process by setting all attribute weights
to a neutral position (that is, make all attribute weights equal). This is achieved by clicking the
button reset null.
3.9
Questionnaire
Ordering relations (comparisons) can be entered by the user by means of the Relations tool; it
is sometimes convenient, however, to have the system suggest ordering relations to the user by
means of a questionnaire. Such a questionnaire comes in te form of a series of questions where the
user is asked to give his / her verdict over a certain statement. This mechanism is provided as an
alternative for inputting ordering relations ’by hand’.
3.9.1
Introduction
When the Questionnaire-tool is started, a sequence of propositions is presented to the user. Every
time the user can invoke a next proposition by clicking on the Next question button. The user
is invited to react on each proposition by clicking one of three buttons, labeled agree,disagree
or no opinion. The ’no opinion’ button should be selected in case the user’s opinion is neutral
with respect to the proposition, or in case the comparison makes no sense.
3.9. QUESTIONNAIRE
53
The propositions are formulated by Assist, in principle using the strategy of maximal mutual
information . Every time Assist generates a new proposition, it applies the following steps:
1. make an inventory of a (random) collection of possible propositions. That is, for some
attribute, consider a combination of two items. The number of possible propositions that
is actually used is a matter of performance; a maximum amount of time is allocated to the
process of suggesting a proposition. On a fast machine, the number of possible propositions
to be scanned in that amount of time will be relatively large. The following restrictions
apply:
(a) combinations that already occur as ordering relations are not suggested - so every
proposition will be new;
(b) combinations that give rise to a proposition that would be a redundant relation are not
taken into account;
(c) combinations that involve two items where one is a more abstract version of the other
are not taken into account.
2. for each proposition, Assist calculates6 what the difference in the present cumulated itemscores would be if this ordering relation would be added to the set of ordering relations. This
is the effect of an ordering relation. Some ordering relations would have very little effect
(perhaps because the weight of the related attribute is small), others may be very significant
(notice that adding a redundant ordering relation would have no effect at all - one further
reason not to consider redundant ordering relations).
3. potential ordering relations are sorted with respect to this effect, and the ordering relation
with the largest effect is presented to the user.
For every response, an ordering relation may be added, as follows:
• if the user clicks ’agree’, an ordering relation conform the proposition is added;
• if the user clicks ’disagree’, an ordering relation is added that is the inverse of the proposition;
• if the user clicks ’no opinion’, no ordering relation is added; the proposition is maintained
in a ’don’t ask’-list, however, to avoid that the same proposition would be asked later;
• if the user’s respons is such that an ordering relation should be added, a check is made (a)
for any cyclic conflicts or (b) for any other inconsistencies with existing relations. In case a
conflict is found, the ordering relation will not be added.
3.9.2
Manual
The Questionnaire form is depicted in figure 3.10. When started, the user can click on a button
Next question. After a while (depending on whether the user wants the maximum mutual
information algorithm to select most meaningful suggestions first - this algorithm can be selected
in the Preferences-form) a proposition appears. For further information, Assist reports how
many possible propositions it took in consideration; this amount depends on the performance of
the machine Assist is running on.
Also, the three buttons agree, disagree, and no opinion appear; the user can make his opinion
known by clicking on one of these buttons.
6 This
is a very expensive process. Unless Assist runs on a very fast machine, only few possible propositions
can be analyzed in this way. For this reason, it is possible to choose in the Preferences form whether or not the
principle of maximal mutual information should be used.
54
3.10
Queries
3.10.1
Introduction
The main part of the Assist data structure is a table where rows (also called records) correspond
to items and columns corresponds either to classifiers or ranking attributes. This is the standard
table-object as it occurs in databases. Such a data structure can be interrogated essentially in two
ways:
• row-based (’extensionally’, or item-based): given a record (that is, given an item), give all
the information for that item in terms of classifier-values and rank-attribute-values;
• column based (’intentionally’, or query-based): given (a) constraint(s) in terms of classifiervalues or rank-attribute-vales, give all items that satisfy the constraint(s).
The Inspire form and the Relations-form allow maintaining the information in a item-based fashion;
to access the information in a query-based fashion, we need the Queries form.
Queries on a data base can take many forms; dedicated languages such as SQL have been devised to
express such queries. Even if the database essentially consists of a single table, obtaining precisely
the records that we are interested in may require a rather sophisticated logical expression. For
instance, we could conceive an expression as
C1 = V1 AN D (C2 <> V2 OR C3 = V3 ) AN D (A1 .low < 20 OR A3 .width > 40)
, which means: ’those and only those items for which the classifiers and ranking attributes satisfy
the given logical formula’. In this expression, C1 , C2 , and C3 are classifiers; V1 . . . V4 are classifiervalues; A1 and A2 are ranking attributes; ’low’ and ’width’ denote the lower bound and the width
of intervals, respectively.
In Assist, we impose some restrictions on the logical formulas that can be used to select items.
The query-expression that is accepted in Assist consists of a list of elementary query expressions,
and the (implied) ’AND’ operator between them. That is: items, to be selected, should satisfy all
elementary query expressions. Elementary queries may involve classifiers and ranking attributes.
For an elementary query involving a classifier and a classifier value, we can use any classifier, and
any of the following operators:
• classifier contains this classifier value (e.g., ’x,y,z’ contains ’x’);
• classifier does not contain this classifier value (e.g., ’x’ does not contain ’p’);
This operator takes as argument a value from the set of values for that classifier.
For an elementary query involving a ranking attribute, we can use any ranking attribute, and any
of the following operators:
• is good (that is, centroid is larger than 50);
• is bad (that is, centroid is not larger than 50);
• is sharp (that is, the width of the interval is less than 50);
• is vague (that is, the width of the interval is not less than 50).
3.11. CLUSTER
55
The total query is given by the conjunct of the elementary queries, that is: all elementary query
expressions have to hold for the selected items. So if the list of elementary query expressions is
empty, all items ares elected; adding an elementary query to the list makes the constraint more
strict, and therefore may reduce the set of selected items.
In any state, when the Query form is active, there is a set of selected items (this set may be
empty, or it may contain all items, or anything in between). The present set can interpreted as
children of a new item, that is: a new item may be introduced that corresponds to exactly the
class of currently selected items (whether abstract or concrete items). This is somewhat similar to
creating a set of parent-child relations in the Relations-form: the user is asked for a name of this
new item; Assist adds this new item, and for all the children (that is, all selected items), Assist
adds include-relations to the new item.
3.10.2
Manual
The Queries form is depicted in figure 3.11. The widgets consist mainly of check boxes. For every
classifier and for every ranking attribute, there is one row of check boxes.
For a row of check boxes belonging to a classifier, we find two check boxes for each of its values.
One of the two is labeled with that value; the other one is labeled by that value, prefixed with a
tilde. Selecting the first check box means that the value should be included; marking the second
check box means that the value should not be included.
For a row of check boxes belonging to a ranking attribute, we find four check boxes in total.
These are labeled with ’good’, ’bad’, ’sharp’, ’vague’ as explained above. Any combination can
be selected. No two check boxes can be selected at the same time that are mutually exclusive,
though: selecting ’good’ and ’bad’ at the same time makes no sense.
For every selection, Assist checks all items to find the ones that meet with the criteria. The
names of these items are colored blue; items are sorted so that all blue colored items appear on
the top.
By clicking the add item button, the user indicates that a new (abstract) item should be added
that represents the current selection. If a valid name is given, this item is created and, when
allowed, inclusion-relations are automatically added to connect this new item with all selected
items; the latter will serve as its children. Also, an estimate is calculated for the rank attribute
values for this new item in the same way as explained in 3.6.2.
3.11
Cluster
3.11.1
Introduction
To get a better understanding of the structure of the set of items, two additional tools are provided
within the Assist system. The first one is clustering; the second one is a visualization of Pareto
fronts. Here we discuss the cluster tool.
As we mentioned in section 3.6.2, when explaining the auto-ranking: between any two items, a
distance can be defined. Such a distance should be zero for items that are identical; it should be
non-negative, it should be symmetrical (distance between A and B equals the distance between B
and A), and it should obey the so-called triangle inequality (the distance between A and B cannot
be larger than the sum of the distances between A and C and between C and B). A suitable
definition of distance as far as classifiers as concerned is the Hamming distance. The Hamming
distance between two items is based on the number of classifiers in which these items differ. A
classifier contributes to the distance inversely proportional to the number of values this classifier
56
Figure 3.11: A screen shot of the queries-form to perform selections on the list of items. In this
case, we only want items for which classifier ’motorized’ contains ’j’ (’yes’), and does not contain
’n’ (’no’). This assures that no items with value ’j,n’ are selected.)
3.11. CLUSTER
57
Figure 3.12: A still from a clustering-visualization. In this case, the slider for the classifier
’chipping’ has been set to a large value; all other sliders are 0. This means that the distances
are only determined by the value of the ’chipping’ classifier, and tow clusters result: one with
chipping tools and one with non-chipping tools.
can take: if two items differ with respect to a binary classifier, this is more significant than when
they differ with respect to an n-ary classifier, n>2.
As far as the attributes are concerned, the distance between items is defined to be proportional to
the difference between the expectation values (=the average between the lower and upper values
of the interval) of their attributes. So for any two items we can compute a distance, which is
a contribution of the distances due to classifiers and due to attributes. This total item-to-item
distance is a (non-negative) number, which can be interpreted as the rest length of some spring.
In this view, all items are point masses, connected via springs. Items that are close together
are connected via short springs; items that have large distance have long springs between them.
When we animate this network of mass points and springs, we get an intuitive view of the clusterstructure among the items.
This is enhanced by the option to vary the influence of the various classifiers and attributes.
For instance, if we fully ignore a particular classifier C, items will belong to the same cluster
irrespective of whether they are equal or not with respect to C. The more classifiers or attributes
we ignore, the fewer clusters will be formed. To see this effect, we associate a slider to each
classifier and to each attribute.
3.11.2
Manual
Figure 3.13 is a screenshot of the cluster tool.
When the Cluster-tool is started, it will display a swarm of icons, each representing one of the
non-abstract items. (Abstract items, i.e., items with more than one value for any classifier are not
rendered in the cluster-view). In the top left corner of the form, there is a series of sliders. Each
58
classifier has an associated slider and each attribute has one. Initially all sliders are set to 0. In
order to study the clustering structure as a consequence of e.g. one classifier, the slider for that
classifier should be moved to a large(r) value. The swarm will then re-arrange to form clusters,
each cluster characterized by one value of the chosen classifier. When a second classifier-slider is
moved up, the clusters will segregate; for instance, if both classifiers have two values, a maximum
of 4 clusters may result.
It is allowed to move any selection of sliders; it will be difficult, however, to give a meaningful
interpretation to the clustering structure when more than two sliders are larger than zero.
It should be realized that the displayed item icons are mass-points in a network of springs. That
means that they are in a dynamic equilibrium. In fact, a small amount of noise is constantly
applied in order to keep the item icons moving. This helps to avoid that two items get stuck on
top of each other, which would hamper readability. For convenience, item icons can be dragged
around; all others will adjust their locations in order to keep the relative distances correct; this
can give further control over the layout of the swarm.
3.12
Pareto
3.12.1
Introduction
For any two attributes, we can plot the graph of all items in a Cartesian coordinate system spanned
by these two attributes. Every item is a dot in this graph; the uncertainty intervals give error
bars to this dot. In case horizontal and vertical attributes are equal, all dots are on a (45 degree)
line, and their order and spacing show the individual item-attribute scores. Such Pareto plots are
very useful to get an immediate understanding of trade-offs (with respect to any two attributes)
between items.
3.12.2
Manual
When the Pareto tool is launched, no ranking attributes are selected, and no Pareto plot is visible.
We select a ranking attribute by selecting the associated check boxes in upper left corner of the
form. The most recently ranking attribute is associated to the vertical direction; the previous one
is associated to the horizontal direction. By twice clicking on the same ranking attribute, this
attribute will be used both for the horizontal and for the vertical ordering: in that case, all items
appear on a diagonal line.
Items that are not dominated are colored green; other items are colored red.
3.13
Folk-ontology
3.13.1
Introduction
Even a large Assist project will contain no more than some 20 items and perhaps 10 or 15
classifiers. The represented knowledge is therefore extremely limited; still, constructing such an
ontology can easily take an hour or more. It can be very interesting, therefore, to combine multiple
ontologies into one, growing ontology that is made available to all participants. This is the folkontology. The prefix ’folk’ means, that the ontology is not the result of some orchestrated effort to
arrive at a consistent body of knowledge, like a traditional encyclopedia. Rather, it compares to
Wikipedia, where knowledge is contributed by multiple, anonymous authors. This means that no
guarantees can be given for the quality of the knowledge: it is possible that it contains disputable
3.13. FOLK-ONTOLOGY
59
Figure 3.13: A screenshot for the Pareto visualization tool. Ranking attribute ’tiresome’ has been
selected to be plotted horizontally and ’macho’ is selected to be plotted vertically. The items that
are non-dominated with respect to these two ranking attributes have been colored green; the other
ones are red.
60
or even wrong statements. For most applications this is a serious problem: if ontologies are used to
reason over a domain, consistency is a stringent requirement. In the divergence phase of a design
process, however, inspiration is more important than factual knowledge. Therefore consistency is
less of an issue.
The folk-ontology used by Assist can be thought of to contain 4 tables: one table with items, one
table with classifiers, one table with values, and one table where these three are coupled. In the
latter table, we can find tuples such as {ball, shape, round}, representing the fragment of world
knowledge that a ball is round.
Since the amount of information in the folk ontology can become huge (at the moment of writing,
the number of tuples is little over 3000), we need some tools to identify the right fragments of this
chunk of world knowledge.
The Folk-ontology form contains these tools.
There are four basic operations.
The two simplest ones are the import from an Assist project from the database, and the export
from an Assist project towards the database.
Two more advanced ones take the form of queries.
3.13.2
Manual
First we address import and export from and to the folk ontology database. These are controlled
by the two buttons in the upper right corner of the form. Notice: exporting information to the
folk ontology database is only allowed for registered users: you have to be logged in for the export
function to be available.
from folk ontology: at any time, an Assist project contains items and classifiers. By clicking
the button from folk ontology, a query is done to the folk ontology database to collect all tuples
of the form {ITEM, CLASSIFIER, VALUE}, where ITEM is one of the items currently in the
Assist table, and CLASSIFIER is one of its classifiers. The value VALUE is filled in into the
appropriate cell. If several tuples exist with the same ITEM and CLASSIFIER, their values are
added all, separated with comma’s. For Assist, the interpretation is that these items are abstract
items - even if this may not be the intended interpretation. For instance: an umbrella is made of
steel and textile. For a classifier material we therefore could imagine the tuple {umbrella, material,
steel and textile}. It is more likely, however, that there will be two tuples: {umbrella, material,
steel} and {umbrella, material, textile}, which suggests that there are two types of umbrella’s:
steel ones and textile ones. There is no provision, neither in the folk ontology nor in Assist to
deal with this anomaly.
to folk ontology (only for users that are logged in): this starts a dialogue where, for each of
the items and for each of the classifiers, the user is asked whether these should be exported. This
means that a user can decide only to export part of the knowledge in the current Assist project
to the folk ontology. Answers are ’yes’ (this item or classifier should be exported); ’no’ (this
item or classifier should not be exported, but next ones may); ’yes to all’ (this item should be
exported, and all following items as well, or: this classifier should be exported, and all following
classifiers as well); or ’cancel’ (don’t export anything and quit the dialogue). When all items and
classifiers have been checked in this way, the values in the cells are used for form tuples of the
{ITEM, CLASSIFIER, VALUE}-form (multiple tuples are formed when one ITEM-CLASSIFIER
combination has multiple values in its cell) and these tuples are written to the folk ontology
database. After that, the relevant parts of the database are reloaded into Assist, so that the new
information is available to other operations in Assist.
Two more advanced options to interrogate the folk ontology are the following.
3.13. FOLK-ONTOLOGY
61
add item query
An item query is a list of items, assembled by the user. These items are selected from the list of
all available items in the folk ontology. An item query is assembled by clicking the button add
item query; a complete-as-you-type dialogue is given to browse through this list (to be called
the item list, sitting in the top half of the form). Items in the item list can be assembled into the
query list, sitting in the bottom half of the screen. Entries in the query list are items, selected by
the user.
As soon as the first items have been entered into the query list, two more buttons appear: do
query, and cancel query. Clicking the do query button performs a query to the folk ontology
database. In this query, first the classifiers, and sets of values, are assembled that are shared by
all items. Suppose that the items are ’bottle’ and ’newspaper’, these classifiers include ’material’
(with values ’glass’ and ’paper’), and ’shape’ (with values ’oblong’ and ’rectangular’). Next it
finds all items for which all shared classifiers are defined, and where the values are among those of
the initial set of items in the query list. This set of items is returned, and presented in a third list,
to be called the result list which spans the entire form. This result list contains all resulting items
(including bottle and newspaper), all classifiers that are shared (including material and shape),
and for each item, the values of these classifiers. Tow new buttons occur: import result and
cancel result. The second one simply removes the result list; the first one adds all items and
classifiers and values from the result list to the current Assist table - as far as they did not yet
occur in Assist.
To modify the list of items in the query list, one can either click on an item in the item list: this
will add an item to the query list. Alternatively one can select an item in the query list and click
on the button delete query; this will remove the selected item from the query list.
The second way to interrogate the folk ontology is by means of a query based on classifiers, by
clicking the button add func query.
A func query is a list of classifiers, assembled by the user. These classifiers are selected from
the list of all available classifiers in the folk ontology. A func query is assembled by clicking the
button add func query; a complete-as-you-type dialogue is given to browse through this list (to
be called the classifiers list, sitting in the top half of the form). Classifiers in the classifiers list
can be assembled into the query list, sitting in the bottom half of the screen. Entries in the query
list are now classifiers, selected by the user; for every classifier there can be zero or more values.
In order to select the appropriate (set of) value(s), the classifiers list is split into two halves as
soon as an entry in the classifiers list is clicked: the admitted values for the selected classifier are
given in the right half of the classifiers list. Clicking on a value adds this value to the classifier
query as it appears in the query list. Clicking again on a value makes it go away; so the collection
of desired values can be easily determined. In the same way as with the item query, a func query
can consist of arbitrary many classifiers, each classifier with arbitrary many values. Classifiers can
be taken out the func query by clicking on the delete query button.
Similar as with item queries: as soon as the first classifiers-with-value-list have been entered into
the query list, the two buttons do query and cancel query appear. Clicking the do query
button performs a query to the folk ontology database. In this query, items are found for which all
of the classifiers in the query list possess one or more of the given values. The output of the query
takes exactly the same form as with the item query: first a set of items; next a set of classifiers,
and for every classifier the set of values assumed by this item. Similar as with the item query, the
result list can be canceled or imported into Assist.
62
Figure 3.14: This screenshot shows the preference tool where various Assist functions can be
controlled.
3.14
Preferences
3.14.1
Introduction
The behavior of Assist in various aspects can be tuned in the Preferences-tool.
3.14.2
Manual
Figure 3.14 shows the Preferences-tool in its default state. The following controls are offered.
allow quick ranking
With every added relation, Assist calculates a default mapping to colors. It is possible, however,
to adjust these default assignments. The standard way to do this is by means of using the sliders
(see 3.8. An alternative method, that is sometimes quicker, is to use the quick ranking tool. The
quick ranking tool is depicted in figure 3.15. If the option allow quick ranking is checked in the
Preferences tool, ranking attribute values can be adjusted directly in the Data Grid without having
to open the Slider tool. If a ranking attribute cell is clicked, a widget appears which contains 15
3.14. PREFERENCES
63
Figure 3.15: This screenshot shows the quick ranking tool, applied to the ranking attribute in
column ’tiresome’ item in the 4th row.
colored buttons. From left to right these buttons are arranged in increasing ’goodness’; from top
to bottom they are arranged in decreasing certainty. So the color of the top left button is bright
red; the top right button is bright green, and the lowermost button is white. Clicking a button
assigns the chosen color to the actual ranking attribute (= the ranking attribute in the actual
column, applied to the item in the actual row). Just as with the sliders, other ranking attributes
are adjusted when necessary in order to keep all relations valid - this includes the comparison
relations as well as the inclusion relations.
Notice: as a consequence of adjusting the ranking attribute value for some item, the item’s total
score is re-calculated. It is possible therefore that the item’s place in the total rank list changes. If
the option ’re-sort after summation’ is set, this means that the item may appear in a different row
- which may be somewhat confusing (in particular since, in general, it will be difficult to predict
when this happens, and what the new rank order number of the changed item will be).
pick values from list
When giving values for classifiers, Assist makes suggestions on the basis of the folk ontology. In
some cases, the knowledge domain that is modeled in an Assist may not benefit from the folk
ontology. In that case, it is quicker to simply type in values without having to select them from a
list. In that case, this checkbox should be un-selected; it is selected by default.
re-sort after summation
By default, any change of any ranking attribute value will give rise to a re-calculation of the total
64
item scores by means of the formula
Sj =
X
Wi Sij .
i
If the check box re-sort after summation is set, items are always sorted in the order of increasing
Sj whenever an update occurs (the order can of course be overruled by sorting the rows ’by hand’
as explained in section 3.2). This is convenient in most cases, but it can be confusing; for this
reason, Assist offers the option to switch off this feature.
hierarchical propagation of classifier values
By default, changes of classifier values propagate through the inclusion-hierarchy. That is, for a
classifier C, a parent item will have at least all values as any of its child items; conversely, a child
item will not have any values that do not appear in its parent item. A change in any classifier
value propagates both upward (in the direction of all parents and their parents) and downward (in
the direction of all children and their children). The consequences can be somewhat unexpected in
rare cases, as demonstrated in section 3.7.3 with the Hover craft, amphibean vehicle and Batcar.
To avoid such surprises, one may choose to switch off the automatic propagation.
A warning is in place, however: if classifier values have been set with the automatic propagation
being switched off, and at a later time the automatic propagation is switched on again, Assist does
not attempt to make all classifier values in accordance with the current set of inclusion relations
(indeed, this would be a non-deterministic process, since it depends on the items where we start).
So it is possible to end up with an inconsistency between intentional and extensional is-a relations
in that case.
number iterations
As explained, Assist applies a heuristic algorithm to make a default assignment of colors to
ranking attribute values in accordance with a set of ordering relations. For every change of the set
of ordering relations, this algorithm is executed again. The algorithm is an iterative algorithm,
and the quality of its result is better when the number of iterations is higher. ’Quality’ here means
the following. Suppose that we have a series of items i1 , i2 , i3 , ... in that are linearly ordered with
respect to some ranking attribute. So there is a full ordering relationship. If we map the values of
these ranking attributes to a numerical scale, we might want the default outcome to be uniformly
distributed. That is: we might want an interval scale, where the difference between the values for
im and im+n equals the difference between im′ and im′ +n . It can be shown that this outcome is
only reached in the limit of infinitely many iterations. With any finite number of iterations, items
’in the middle of the range’ will typically be packed closer than items near the extremes. For very
few iterations and a complicated set of ordering relations it is even possible that no assignment
of values can be found that is consistent with the set of ordering relations. Therefore it may be
necessary to adjust the number of iterations. The following trade of applies:
• advantage of large number of iterations: high quality, large probability that a solution will
be found;
• disadvantage of large number of iterations: updating the configuration of relations may be
slow (i.e., the questionnaire will take a while in processing the answer to a question; when
the smart questionnaire option is selected, only few candidate propositions can be tested
in the limited amount of allowed time to give a possibly meaningful question, and adding or
deleting relations in the Relations-tool may take a while).
It is recommended to play a bit with the setting of the number of iterations. If Assist reacts slow
it could help to bring the number of iterations down; if it frequently occurs that adding a relation
gives the error message that the process could not be completed ’because safe adjust returns false’,
it could help to increase the number of iterations.
3.14. PREFERENCES
65
color coding items: Pareto
When item scores are (re-)calculated, the results are given in color codes in the column itemRank.
The column itemName, however, can also reflect the results. If the option color coding items:
Pareto is chosen, the color scheme indicates the state of affairs in Pareto-sense. Itemnames that
are colored green are on the Pareto front (that is, they are not dominated); dominated items are
colored red.
color coding items: intervals
When item scores are (re-)calculated, the results are given in color codes in the column itemRank. The column itemName, however, can also reflect the results. If the option color coding
items:intervals is chosen, the color scheme indicates the state of affairs in interval-sense. Item
names on a green background are better than any other item; those that are red are worse than
any item; items that have their names on a yellow background are both better than any item and
worse than any item; items that are neither better nor worse than any item have white item name
fields.
ranks as colored boxes
Rank item values and item scores are mapped to colors as explained above. Colors reflect two
ordering systems at once: the comparison order in the hues and the certainty order in the saturation. This mapping to colors has the advantage that we don’t have to bother about whether
scales are interval scales or not. In rare circumstances, however, we might want to be informed
about the numerical outcome of Assist’s color assignment algorithm, or we might want to see
what adjustments we have made to the default values. In that case the option ranks as colored
boxes should be de-selected: in that case numerical values are given in the rank attribute cells
and the cells in the column ’itemRank’.
smart questionnaire
The questionnaire can use a maximum-mutual information strategy to pose more relevant questions
- that is: questions that will lead to a sharper distinction. This process requires large amounts of
calculations, however, which means that on a typical machine, not too many possible solutions can
be analyzed in the limited time that is allowed for this operation (indeed, since the questionnaire
is an interactive process, a next question must be available within few seconds after the user has
clicked the next question button). Therefore the smart questionnaire option can be switched on
or off, depending on the speed of the machine and the patience of the user.
IO: use local disk space: use the ’cookie’-kind of storage;
IO: use remote database: use the remote database modus of storage (not recommended; only
provided for backward compatibility);
IO: use remote files: this is the recommended storage mode;
IO: export or import as XML: for using Assist projects in other applications;
folk ontology language=dutch: the folk ontology system supports two languages: English and
Dutch. Preferably, the English language should be used; if the language is switched to Dutch, a
smaller vocabulary may be supported.
66
Chapter 4
Modeling: a Systematic Approach
’Models are made of variables. Invariably.’
4.1
The notion of a Model
Designing amounts decision taking. Professional design means: taking justifiable decisions. In
order to justify our decisions, we should understand their consequences, and we should take the
decisions such that the most beneficial consequences arise. These consequences, however, cannot be
observed yet: the decisions under consideration will only affect a future state of things. Therefore
we need models to predict the consequences as they result from (design-) decisions.
The notion of a ’model’ is very common in the daily practice of engineers and scientists. There is
quite a bit of confusion of the precise meaning of ’a model’, though. For our purpose, we will take
the notion of a model to mean three things:
• an intention or a purpose (what do we want to use the model for?);
• a set of assumptions (propositions that are not discussed);
• a consistent framework of model statements, which allow designers to take decisions (the
actual ’body’ of the model that forms a representation of a relevant part of reality).
The ’reality’ that the model refers to will both relate to the existing reality and the future reality,
as it will appear after the design is ready. These two aspects make a very big difference. When
we want to make a model about an existing (part of) reality, we can hope to verify some of the
model statements by means of observations. Indeed, reality can be observed, maybe by means of
experimental, empiric measurements. If we measure correctly, observations of the same piece of
reality are assumed not to be inconsistent, and this is a strong check of the validity of our model.
When we want to make a model (part of) the future, however, we cannot use experiments. We
cannot measure future things. The system we want to measure doesn’t exist yet, because we are
still designing it. So there is no simple guarantee that two model statements will be consistent.
67
68
CHAPTER 4. MODELING: A SYSTEMATIC APPROACH
This indicates that the consistency of models for not (yet) existing pieces of reality is a serious
and non-trivial issue. To give at least some ground to our reasoning, we will often make use of
mathematical models in designing. Indeed, since we want our models at least to be consistent, we
can benefit of the consistency that is offered by the language of mathematics.
4.1.1
Different intentions require different models
In many contexts, a model is understood to consist only of ’a (hopefully consistent) framework
of model statements’. We will show that this is clearly insufficient. The intention is a necessary
part of the model, and thinking about the intention should form a significant part of the effort of
model building. We will illustrate this problem by means of a typical industrial design example,
namely a corkscrew.
First, consider figure 4.1. This depicts the corkscrew ’as it is’. A photo is, in some sense, ’real’:
everything that is really there can be photographed. There are no deliberate approximations or
omissions. There are very few purposes, however, where we need a complete rendition of the
object we want to model. In all circumstances, where we need a model in order to answer a
particular question about the modeled object, we need to focus on these aspects of the object that
are necessary to answer the question. This gives rise, in principle, to a dedicated model for each
question we want to be solved.
We illustrate this by three different questions, shown in figure 4.2. First of all, a model for the
entire corkscrew could consist of a cylindrical shape with the overall dimensions of the corkscrew,
as shown in figure A. Such a model could be useful, for instance, for establishing the dimensions of
the packaging. On the other hand there is a model that shows the actual looks of the corkscrew.
(B). This could serve in a decision process regarding various shapes of the handle; since the decision
only regards the shape, we need to provide neither material properties, colors nor dimensions. The
last model (C) could be useful in arguing about ergonomics: the pitch should be such that inserting
the corkscrew in cork should not require too much torque, whereas at the same time pulling the
cork by the screw should not cause it to break; similarly, the point angle should be small enough
so that the screw can be inserted in the cork, and should be not too small so that a serious safety
hazard results by careless handling.
We have now made some very different models that are each adequate only when we know what
intention they should fulfill. There is a risk that these models become inconsistent, and the
designer has to safeguard against these inconsistencies.
Prior to develop a model, we should be very certain about the purpose we will be needing the
model for. Omitting the intention of a model makes the effort of building that model a useless
waste of time.
4.1.2
The role of assumptions
We have seen the necessity to have a clear understanding of the role of intention when we want to
build a model. The role of the assumptions is a subtler one. If we accept that the ’total’ context
of a design situation is always too large to handle completely, if follows that the arguments and
decisions are only made within the current model(s). A ’correct’ decision at best means ’a decision
that is consistent with the statements in the current model(s)’, and therefore consistent with the
assumptions that underlie those models.
Indeed, the model(s) take(s) over the role of the real design context, as the designer’s mind is not
capable to deal with the entire reality, and the ’real thing’ does not exist yet. This suggests the
following scheme (see figure 4.3:
step 1: assumptions result from the designer’s intuition and experience; however, they need not
4.1. THE NOTION OF A MODEL
69
Figure 4.1: A photograph of a corkscrew.
to be ’correct’ or ’complete’ in some sense. Remember that reality is always more complicated than we think, and the assumptions serve to abstract (= to simplify) from reality.
Assumptions can, at best, only be ’reasonable’. To a large extent, they are non-unique and
subject to negotiation.
step 2: since assumptions cannot be verified as being objectively ’correct’, they can only be
assessed as (subjectively) ’reasonable’. This assessment should therefore be, ideally, an
agreement (’contract’) between the designer and the stakeholder(s). This means that the
designers is not solely responsible for the absolute correctness of his design decisions: he is
only responsible for the decisions being consistent within a model that in turn is consistent
with the assumptions. Since these assumptions were agreed upon with the stakeholder, the
responsibility for the assumptions is shared between designer and stake holders.
step 3: stake holders in general will not have the competence to build models. The construction of the model(s), that should be consistent with the assumptions, is in those cases the
sole responsibility of the designer. This model is the source of justification for (all) design
decisions, so this model plays a crucial role in the entire design process. Therefore, a designer should pay ample attention to model building; a professional designer should be a
professional model builder.
In practice, the distinction between the various phases and steps may not be very clear. In some
cases, this is no problem. If the design is relatively simple, if it is not very innovative, or if no
large amounts of money are involved, it is not necessarily disastrous if some phases are skipped.
On the other hand, many dramatic court trials could have been avoided if designers would have
paid (more) attention to the phase of identifying assumptions and would have negotiated these
assumptions with their stake holders.
Finally, the steps and phases in the above scheme are not necessarily taken in sequential order:
some assumptions are ’discovered’ only when part of the model is already built.
70
Figure 4.2: Three different, complementary models of a corkscrew. A: a model of the global
geometry, ignoring all internal details; e.g., necessary for packaging. B: a visual rendition to show
the shape of the handle, e.g., necessary in decision making about the handle to be used; C: a
model of the pitch and the top of the corkscrew, e.g. used to deal with the trade-offs between
ease-of-use, mechanical integrity, and safety.
71
Figure 4.3: Four phases in designing an artifact, using a model. The two left most phases mainly
relate to identifying assumptions and negotiating assumptions with stake holders. Once the assumptions have been established, the model(s) should make consistent usage of these assumptions,
and the validity of the resulting artifact (under the assumptions agreed upon earlier) can be logically justified.
4.1.3
Multiple models co-exist in any design process; consistency
Even in our corkscrew example, we have seen that we often require multiple models at the same
time in a design situation. Each of these models is a very restricted view to ’reality’ (existing
reality or future reality). Typically, we use one model to justify one decision, and another model
to justify another decision. If these models are independent from each other, it is very conceivable
that the decisions end up being inconsistent. Inconsistency between models is a very common
source for confusion or worse. The mathematic models that we will introduce later have the
main advantage that, provided that two models use the same mathematical language, and the two
models use the same set of variables, consistency follows from the fact that mathematics itself is
consistent.
4.1.4
Purposes for models in design
After our first encounter with models, we can say that models serve the following purposes:
• form a summary of the part of reality that is relevant for the design process at hand;
• facilitate the negotiation and justification of design decisions among designers and between
designers and stake holders;
• allow a distinction between the intuitive part of a design process (= the part where assumptions are identified) and the rational part of design process (= the part where consistency
of design decisions is to be ensured).
Further, we remember that designing is a process of taking decisions such that in a future situation,
one or more stake holders will become happy. Therefore, a model
• should allow to predict the future consequence of a decision.
72
4.1.5
Requirements on models
To fulfill these purposes, a model should meet with the following requirements:
• it should be sufficiently rich (= contain sufficiently many aspects of the design context) so
that the designer can safely base his decisions on the model;
• it should be sufficiently simple to ’fit in the mind’ of the designer (or to fit in a computer
in such a way that the designer feels confident to deal with the model). In particular, the
designer should be able to verify the behavior of the model, to check tat it corresponds to
his/her intuition, and therefore to trust the model;
• it should be sufficiently precise that consistency of decisions can be assessed and predictions
can be made. The model has to be consistent with both internal and external findings.
A model is not consistent with internal findings, if it can lead to two opposite conclusions.
In case of external findings, one could think of measurements from ’reality’ (e.g. physical
phenomena) or results from other models.
• it should not be too precise: the assumptions that lie at the basis of the model necessarily
cause simplifications with respect to reality. These simplifications give implicit upper bound
to the precision of any conclusion that can be drawn from the model. A model should not
attempt to be more precise. This pseudo-accuracy is a serious source of waste of energy,
confusion, and unjustified expectations in the communication between designers and stake
holders.
4.1.6
Variables and relations
Variables form the main ingredients of any model.
Designer’s decisions are based on models, and the justification of a decision follows in a logical
and consistent manner from those models. The models are built and used as an integrated part
of the design process. A model consists of variables and relations between those variables.
We define a variable as a container that can hold a chunk of information. For instance, for a
corkscrew that is to be designed, a variable could be ’the material of the handle’, with possible
values ’wood’, ’plastic’, ’glass’, et cetera. The contents of variables are allowed to change (hence
the name ’variable’)- but they don’t have to. A constant is just a special kind of variable.
In the context of developing our models, we will encounter some variables that contain numbers,
others contain words, geometric figures, etc. In order to manage variables, we will assign names
and types to them. A name will be a word that is any combination of letters and digits. A type
defines the type of information that can be held in the variable.
Type of a variable
In our example of a variable being the material of the handle of the corkscrew-to-be-designed, it is
clear that ’orange’, ’Wednesday’, or ’12’ would not be allowed chunks of information to be kept in
that container. In another example, when the color of an umbrella is considered to be a variable,
’orange’ would however make perfect sense. Apparently, a variable cannot hold any arbitrary type
of information. With a variable we associate a type, which can be defined as the set of things
it can contain. The type of a variable is the set of all possible chunks of information that this
variable could hold.
In many cases, we have to deal with information that is numeric, e.g. with numbers continuously
ranging from 1 till 10. In other cases, we have to deal with information that is discrete, e.g.
{1, 2, 3, 4} or {red, white, blue, green}, et cetera.
73
Value of a variable
We can talk about the relation between a variable and the chunk of information it currently holds.
We say that the value of a variable V is C if C is the chunk of information, currently stored in V .
Relations
Relations express that values of various variables are not independent, hence they give the connection between different variables. Relations can be divided in two sorts:
• functional
• non-functional
A functional relation is a relation that amounts to a (mathematical) function. A mathematical
function is a recipe to produce an element of a set (called the range) given an element of a set
(called the domain).
An example of a functional relation is: y = x2 . Here, x can have all possible values and is part
of the domain and only one possible value of y follows from the relation for each x and is part of
the range. A function does not have to be a result of a calculation: if the domain consists of the
names of various persons, then the corresponding range could consist of the places of birth.
In design, eventually everything (with respect to modeling) boils down to expressing the stake
holders’ happiness as a function of design decisions. Therefore the most useful relations, as far as
constructing models for design is concerned, are functional relations.
A value from the domain of a non-functional relation (often misleadingly referred to as ’implicit
functions’) has multiple possible outcomes. An example of such a relation could be: y 2 + x2 = 1.
It constrains the value of x when y is given, and it constrains the value of y when x is given, but
it does not allow to compute y from x, nor vice versa.
4.1.7
Categories of variables
Variables are the major components of a model. As we have seen a variable comes with a type,
which is the set of values that the variable can contain. In order for variables to act in a model,
however, we also need to pay attention to the various roles that variables can play in our model. We
recollect that designing was defined as ’taking decisions in order to increase the future happiness
of stake holders’. In order to successfully tackle a design problem, it is very important to allocate
the variables of interest to the proper category, which indicate the various roles.
Categories I and II
There are, at least, the following two roles for variables:
I. Variables where the values result from autonomous decisions of the designer;
II. Variables where the values represent the amount of happiness of the stakeholder(s).
Examples of category-I are the choice of material for a certain compound; dimensions of a certain
part; configurations for a certain network, et cetera. Examples of category-II are the energy
consumption, the expected failure rate, the ease of control, et cetera.
74
For each of the variables of category-II, we can say that it should be as large as possible (e.g.,
performance, speed) or as small as possible (e.g., price, environmental impact). In other words,
the variables in category-II need to get optimized (optimized can either mean maximized or minimized ). We will see later why we had to add the predicate ’directly’ in the definition of category-II.
Dependencies
It is important to establish the dependency relations between variables in categories I and II.
First, we can argue that variables in category-I depend on variables in category-II. Indeed, a
designer who wants to achieve certain goals will take his decisions in dependency of these goals.
For instance, in order to meet the goal of ’the mass of an artifact must be as small as possible’,
she will choose aluminum rather than concrete for the main components. So the choice of the
designer gives rise to a dependency of the form v1 = g(v2 ) for variables v1 and v2 belonging in
categories I and II, respectively.
On the other hand, we can argue that variables in category-II depend on those in category I.
Indeed, once the choices have been made, and the artifact is realized according to these choices, it
will manifest itself, and it will display a certain behavior. The properties, represented by variables
in category II, follow from this manifestation and this behavior. So this gives rise to functional
dependencies of the form v2 = f (v1 ).
However, if we want to construct a (mathematical) model, the simultaneous existence of both
types of functional relations, v1 = g(v2 ) and v2 = f (v1 ) is extremely awkward. Therefore only one
type of dependency is desirable.
Category I : independent, autonomous; Category II : dependent
In order to arrive at a simple protocol for developing mathematical models that should support
designing, we demand that v2 is to be regarded as dependent, and v1 as independent. So we only
admit functional relations of the form v2 = f (v1 ), and we forbid relations of the form v1 = f (v2 ).
There are three arguments for this choice:
• First, design decisions always affect the future, so the variable v2 assumes its value at a later
time than v1 . In accordance with our understanding of causality, the later occurrence of a
value for v2 depends on (= may be caused by) the earlier decision of the value of v1 - and
not the other way round. In the example of the mass of an artefact (a category-II variable)
and the choice for a material (a category-I variable), this is clearly visible. Indeed, the mass
of the object is the sum of the masses of all components. So if we now choose aluminum
for one component, and tomorrow we choose glass for another component, the mass will be
the sum of the weights of the aluminum component and the glass component. But the mass
will only be known after all choices have been made. We could say that the mass gets its
definitive value ’later’ than the values of the individual category-I variables.
• Second, a designer is autonomous in his design decisions. Even though value w1 for variable
v1 would give the best result for, say the performance of the artifact, the designer is free
to choose another value, say w1′ . This is even quite probable, since there will be several
variables in category II that together define the goal of the design (or, to put it differently:
that together model the happiness of the stakeholder). Typically, trade-offs have to be made.
• Third, the function f will, in most cases, have no inverse. For instance, suppose that v1 ,
being one of the variables in category II is the mass of the artifact, and v1 , being one of
the variables in category I, is its color. Let us assume that the color does not affect the
mass: then v2 does not depend on v1 . In other words, v2 = f (v1 ) is a constant function,
and therefore its inverse f −1 with v1 = f −1 (v2 ) does not exist. As another example, we look
75
again at the mass of a compound object consisting of several components. From the value
of the mass we cannot deduce the mass of the components (’8’ could both be ’4+4’or ’5+3’);
given the masses of the components, however, the mass of the total compound object follows
uniquely.
The conclusion is that variables in category I are independent variables, and variables in category
II are dependent on variables in category I. So we have:
I. Variables representing free, autonomous decisions (choices) by the designer;
II. Variables representing the happiness of the stake holders.
Finding category-II variables from category-I variables
Designing amounts to optimizing stake holders’ happiness; therefore, ideally, we should start
any design process by identifying exactly what constitutes this happiness. Initially, we should
completely ignore any hint of a solution; there should be no category-I variables at all, since any
premature idea of what the artifact could look like would constrain our solution space - or worse:
it might bias our solution space to something that would be less than optimal in view of the
intended stake holders’ happiness.
This might be illustrated by the following story: once upon a time, a customer approached an
industrial designer with the request to design a corkscrew. Based on his common sense of what a
corkscrew should do, the designer could start from a mental image somewhat like figure 4.1, and
she could start thinking of category-I variables such as the material of the handle; these categoryI variables influence such aspects as price, robustness and ’looks’, so she could verify with the
customer if these are suitable category-II variables. Our designer, however, follows a different
route. She starts the following dialogue.
Designer: ”What is the corkscrew to be used for?”
Customer: ”To remove a cork from a bottle of wine.”
Designer: ”Why do you want to remove a cork from a bottle of wine?”
Customer: ”In order to let the wine out of the bottle and pour it into a glass.”
Designer: ”Why should the wine be poured into a glass?”
Customer: ”To facilitate drinking it.”
Designer: ”Why do you want to drink wine?”
Customer: ”Because I want to get drunk.”
Designer: ”Why do you want to get drunk?”
Customer: ”Because I want to forget my sorrow related to my bad marriage.”
Designer: ”Why do you want to forget your sorrow?”
Customer: ”Because it makes my unhappy, and I want to be happy.”
The above dialogue illustrates various interesting aspects from design processes, the role of biases,
and category-I and category-II variables.
• The dialogue stops at the point where the customer mentions that ’something will make
him happy’. It is regarded as an axiom that people want to be happy; the question ’why do
you want to be happy’ is therefore not in place. Ideally, however, any interrogation as to
what purpose should be fulfilled by the artifact-to-be-designed should continue to the level
’... because this is what constitutes (part of) my happiness’.
76
• Each of the intermediate answers (purposes) could have been realized in many more ways
than by the given approach. For instance, in order to remove a cork from a bottle, we could
push it into the bottle, we could drill a hole in it or we could burn it. The solution to use a
corkscrew is merely a default solution, which pops into mind first, and which usually blocks
any further thinking.
• Concluding that, for instance, the ease of removing a cork from a bottle would be a categoryII variable is premature if a little while later it becomes obvious that ’a corkscrew’ is perhaps
not the best possible solution to remedy the customer’s unhappiness. Instead, promising
solutions could be sought among those that address intentions that are close to ’... because
it makes me happy’. In the present case: consult a marriage councillor, get a divorce, or take
a mistress. Associated category-II variables could relate to the intentions of the customer’s
wife (does she want to continue her matrimonial state?), to the moral standards of the
customer (is divorce acceptable?) or to his ability to attract women (is it possible for him
to find an interested lady?)
The above way to obtain the ’true’ intention of the artifact-to-be-designed (and therefore, the
’true’ category-II variables) may be the most ’pure’ in the sense that it allows the broadest possible solution space (after all, a corkscrew is still a possible solution, so it is included in the solution
space; together with a device for drilling holes through corks, the address of a bar where cheap
liquor can be obtained, and an appointment with a marriage councillor). Furthermore, it is the
’purest’ in the sense that it attempts to keep the influence of (implicit) default thinking to a minimum. At the same time, it is a very idealistic and, in many contexts, not so very practical route.
Imagine an engineer designing a specific component (say, the control software for a cooling water
pump) of a much larger installation (say, an electric power plant). Reasoning along the above lines
would, along the way, produce questions such as ”why should electricity be generated by means
of fossil fuel”, and even ”why do the citizens of X require energy?” These questions are extremely
relevant, and they can lead to drastic innovations that have major economic, environmental and
even existential impact. But they are presumably not supposed to be addressed by the engineer
who is responsible for the software to control the cooling water pump. Design processes take
place at various levels, from overall system design level (such as the development of technological infrastructure or socio-economic aspects of governmental policies), to the very much detailed
level (such as the choice of a particular statement in a software program or a particular electronic
component in a logic circuit). At each level, a sequence of questions leading to the assessment of
happiness of stake holders can be constructed, but this sequence has varying relevance depending
on the size of the problem and the expected impact of the solution.
So, the question remains: if a complete ’how-does-this-lead-to-happiness’-analysis is not feasible
how then can we obtain meaningful category-II variables? A related question is: suppose that we
don’t want to explore the entire solution space, how should we find category-II variables if we want
to find an ’optimum’ in a restricted solution regime (that is, we have an idea how the solution
should look like - we ’merely’ have to decide a number of its parameters)?
In this case, strictly speaking, we started from the wrong side. We have a number of category-I
variables, and in order to choose optimal values for them, we should construct reasonable categoryII variables. Even though this is the wrong side to start the process, in many cases it is the most
practical side - if only we approach the problem to find suitable category-II variables in the proper
way. We can do so as follows.
First, we assume category-I variables of ordinal type (say, a range of numbers). By definition,
these can be chosen freely, so we could do the thought experiment of making them extremely
large or extremely small1 . If we seek such extremes, the artifact-to-be-designed will develop into
something that, eventually, may no longer capable to perform its purpose. Analyzing the precise
1 In
case numbers are inherently natural numbers, ’extremely small’ means zero.
For instance, the
smallest number of doors in a building is zero, which essentially means ’no doors at all’ which suggests buildings such as the famous Mies van der Rohe pavilion for the 1929 world exhibition in Barcelona
77
Figure 4.4: A cloth drying rack.
reason why it ceases to be useful must reveal the reason why, for a less extreme value, the artifact
is useful, in other words: it must reveal one or more category-II variables.
As an example, consider a cloth-drying rack, such as in figure 4.4.
Two obvious category-I variables are N , the number of rods, and D, the distance between two
adjacent rods. Applying the above reasoning gives the following results:
• limN →inf gives an extremely large rack. Obviously this is unwanted; hence, it is plausible
that a ’good’ cloth-drying rack should occupy minimal space. The occupied space is therefore
a meaningful category-II variable.
• limN →0 gives a rack without rods. This cannot support any pieces of clothing, which renders
the cloth-drying rack useless. So, a second category-II variable is the number of pieces of
clothing we can hang on it.2
• limD→inf gives a rack that occupies an infinite amount of space - which produces again the
category-II variable ’amount of occupied space’.
(http://www.designboom.com/portrait/mies/barcelona.html). In other cases, temporarily ignoring the fact that
the default interpretation of a variable would be a natural number can lead to other interesting concepts. For
instance, the amount of legs underneath a table seems to be a natural number that cannot be less than 0. So the
question is: what would a negative number of legs inspire to? The interpretation that an ’inverted’ leg is a suspension cable is not outrageous, so this leads to a table as a platform hanging from something. ’Inverted’, indeed: a
traditional table leg is loaded by a compression force; a suspension cable is loaded by a negative compression force.
2 We could try the option of a negative number of rods. This means that we first must give an interpretation
of an ’inverse rod’. This could be an absent rod - in other words: a hole or a pair of holes in which a rod could
be mounted. In other words: we invented an extendible cloth-drying rack. No we can take a further step: what
happens if this number of holes goes to infinity (in other words, the case limN →− inf : obviously, a rack with too
many holes in it would get very unstable. So: stability is another category-II variable.
78
• limD→0 gives a rack where the rods are extremely close together - which is bad for drying
(indeed, to dry, air must be able to pass between pieces of clothing). So a new category-II
variable relates to the amount of air that can pass in between adjacent pairs of rods.3 .
Notice that the process of sending (ordinal) category-I variables off to their extremes quite often
gives insight into fundamental trade-offs that are hidden in the design problem. In the present
case of the cloth-drying rack, the amount of accommodated pieces of clothing and the occupied
area form a trade-off. This trade-off is closely coupled to a second trade off: the amount of
accommodated pieces of clothing and the drying efficiency (the closer the rods, the more pieces of
clothing, and the slower the drying). This automatically introduces a further category-II variable:
the drying efficiency, perhaps operationalized by the amount of time it takes for a fully loaded
rack to dry. The simples possible model, relating all category-I and category-II variables would
be (ignoring the exotic cases of negative N or negative D:
• minimize N × D (area);
• maximize N (amount of clothing that can be accommodated);
• maximize N × µ(D) (drying efficiency; µ is some monotonically increasing function that
approaches a constant, asymptotic value for D sufficiently large, to express the effect that
clothing hanging too dense won’t dry).
Next we consider the case where a category-I variable is not ordinal. Of course, taking (numerical)
limits makes no sense. Still, the same line of thinking may be followed: substitute extremely
implausible values for the category-I variable will result in unwanted behavior of the artifact-tobe-designed, and, after further analysis, it will reveal a category-II variable. We elaborate again
on the example of the cloth-drying rack. The choice of material of the rods is a category-I variable.
Implausible values are, for instance, paper, uranium, gold, or glass. Analyzing the reasons why
these materials won’t work teaches us:
• paper would fall apart due to the dampness, so the material should endure water;
• radioactive uranium would contaminate the cloths, so the material should not leave any
traces (of dirt) on the clothing;
• gold is outrageously expensive, so the material should be cheap;
• glas is rather vulnerable, and gives dangerous splinters when it breaks, so by breaking or
damaging, the material should not produce any harmful debris.
Finally, for the creativity buffs, we can use the method again to get inspiration for non-conventional
alternatives to the cloth-drying rack:
• paper inspires to think of blotting paper : why not develop a drying concept that is based on
absorption of water by means of some contact substance?
• uranium (which heats itself due to radioactivity) inspires to use some exothermal reaction
to produce heat to dry clothes, perhaps using substances that can be mixed with detergents.
This technology is used, for instance, in self-heating coffee cups that allow hot coffee to be
sold in large public events without the need of kingsize boilers.
3 D is not a natural number; it is a real number, but its interpretation is ’distance’, therefore it cannot be negative
either. Of course this stimulates us to think of an interpretation of D < 0. In some applications of geometry, we
use ’negative distances’. For instance, the distance between a point and a circle is sometimes counted negative
when the point is inside the circle. Talking about inside: this relates to the rods being hollow: perhaps the drying
process of the cloth-drying rack would be improved if hot air would be blown through the rods (perhaps the rods
then should slowly rotate to allow the cloths to be dried more evenly).
79
• gold is a shiny material, mystic symbol of the sun, which alludes to the use of reflected
(sun)light to dry clothing (perhaps using a burning-glass to concentrate sunlight).
• glass is transparent, which associates to the notion of inspection: a simple sensor could make
up for an intelligent cloth-drying rack that could warn the user when the cloths are dry.
Category-III: contextual variables
In order to build a model for a design case, we will probably not be able to write down the
dependencies of variables in category II on those in category I right away. Typically, models are
built up incrementally adding variables one by one.
In doing so, we will most likely encounter variables that are neither in category I nor in category
II. For instance, suppose that we are designing a commodity, and we want to optimize the amount
of profit that will result from selling it. Let v2 = the total income, and v1 = the selling price. It
is clear that v2 = f (v1 ), but we cannot write down function f unless we know how many copies
will be sold. We can reasonably assume, however, that there will not be more copies sold than
the number of people living in, say, the Netherlands. (Assume that this is a type of commodity,
of which people only posses one copy, like a refrigerator). So there is a new variable that enters
our model: v3 = the number of inhabitants in the Netherlands. Clearly, v3 is not in category I:
we cannot autonomously decide on the population of the Netherlands. Also, v3 is not in category
II: we cannot hope that v3 will increase (or decrease) as a result of one of our decisions; neither
will the increase or decrease of v3 increase the happiness of our clients. Therefore we need a new
category:
III. Variables representing quantities in the context of our design, which don’t depend on the
design decisions. Variables of category III are determined by external circumstances, e.g.
physical constants or customers’ demands. The designer has no opportunity to adjust the
values of such variables
Variables in category III are assumed not to depend on any of our design decisions, but the values
of (some or all of) our objective variables may depend on them.
Category-IV: auxiliary variables
Finally, we will encounter variables in a 4th category. Indeed, let us stay with our example
of defining the selling price of our commodities. It is obvious that not all inhabitants of the
Netherlands will buy a copy, but only a certain percentage, say v4 . So we get that the product
of v3 and v4 is the number of sold copies. It is clear that v4 is not in category I, since we cannot
autonomously decide how big it will be. Indeed, people are free to decide what they want to
buy - although we perhaps can influence their decision somewhat by the decision to invest in
advertisements. So v4 could be a function of a category-I variable - in this case, the amount of
investment in advertising.
Also, v4 is not in category II, since the happiness of the stakeholder does not directly depend on
v4 (even though it does depend on v4 indirectly, but category II was about those variables that
directly represent stakeholders’ happiness). We are not necessarily performing better if v4 is big
and v1 is small or if v4 is small and v1 is big. It is only the product v1 v3 v4 = v2 that should be
optimized. Finally, v4 is not in category III, since it does depend on the outcome of our choices.
(For instance, if v1 will be outrageously high, v4 will be close to 0). Therefore, it must be in a 4th
category:
IV. Variables representing quantities that depend on variables in categories I or III, and that
influence variables in category II, but that themselves are not in category II.
80
Category
May depend on
I
independent
decision variable
nothing;
autonomy of
the designer
II
objective variable
all categories
III
contextual variable
IV
auxiliary variable
nothing;
beyond the autonomy of the
designer
all categories;
variables in
categories II
and IV may depend
on these
variables.
Meaning w.r.t. the
design decisions
Represents the
design decisions
Type
Example
any
Represent goals;
the variables in
category I should
be such that variables in this category are optimized
Ordinal,
numeric
dimensions,
materials,
configurations
of the ATBD
(=artefact to be
designed)
optimized
performance,
quality, profit
related to the
ATBD
any
any
social and geographical circumstances; legislature;
physical constants
internal parameters
of the ATBD; variables
that are affected
by the ATBD but that
are not mentioned in
the objectives.
Table 4.1: A taxonomy of the four categories of variables in a model
A second distinction between variables in design models
Now we can make a second distinction between various kinds of variables. All variables of the four
different categories can be subdivided in three types:
Nominal: values that have no ordering (e.g. French, British, Dutch)
Ordinal: values that do have ordering (e.g. hardness of material)
Numeric: values that do have ordering (e.g. temperature)
Variables of category I, III and IV may be of any type: ordinal, nominal or numeric. Variables
of category II, however must be either ordinals or numeric. Indeed, we need to be able to rank
one solution relative to another, and ranking requires an ordering. For each of the variables of
category II, we can say that it should be as large as possible (e.g., performance, speed) or as
small as possible (e.g., price, environmental impact). The properties of the four categories are
summarized in table 4.1.
As mentioned before, it is important to properly allocate the existing variables to one of the categories. In literature and daily design practice it occurs only too often, that designs are optimized
in a non-category-II variable. Also, in practice, category-I variables are sometimes not optimized
at all: they receive a value as a result of a default choice. There can be good reasons for not
optimizing a category-I variable (for instance, because the expected benefit in terms of improved
values for category-II variables does not compensate for the effort), but it is generally a good idea
to be aware of this choice.
81
Nomenclature
In the sequel, we will heavily make usage of a number of key words that are relevant for a systematic
approach in design.
Concepts: the things that are relevant, because
• they come to mind;
• they occur in a type (see below).
Attributes: the chunks of information that need to be known for a concept in order to serve in
the model we are building;
Values: the value of an attribute is the information that is currently stored in an attribute. Values
can be a result of:
• measuring (typically for category III);
• computing (according a model; typically for categories II and IV);
• (educated) guessing (typically for category III; sometimes in category IV if we don’t
have a model (yet));
• choosing or deciding (typically in category I);
Notice that a value can also be a concept in its own right. For instance, consider the
attribute ’shape’, for instance applied to the concept ’dish’. Values of ’shape’ could be, for
instance, ’round’ (for a round dish) and ’rectangular’ (for a rectangular dish). But the value
’rectangular’ means that the shape is a rectangle, and a rectangle is by all means a concept.
Indeed: a rectangle contains information that can be accessed by means of attributes (such
as ’width’, ’height’, ’area’, ’perimeter’, and others). In this case we say that the type of the
attribute ’shape’ is a compound type: a type where values are concepts rather than atomic
values. Atomic values, also called simple values, are values such as ’1’, ’orange’, ’Wednesday’:
there is no further information embedded within atomic values. When no risk of confusion
exists, we apply the notions ’compound’, ’atomic’, and ’simple’ both to attributes and to
the values that can be stored in these attributes. So ’shape’ is a compound attribute, and
’rectangle’ is a compound value. A type that is not a compound type will be called an atomic
or simple type. Simple types are, for instance, numbers, colors, Booleans, week days, ...
Variable: an attribute applied to a concept. For instance, ’radius’ is not a variable, but an
attribute. The radius of the front wheel of my bicycle, however, is an attribute of the
concept ’front wheel of my bicycle’, and is therefore a variable.
Type: a set of all possible values an attribute may take;. When no risk of confusion exists, we
can also refer to ’the type of a value’, for instance: the type of ’3’ is integer.4
Relations: relations, other than functional relations, express that values of various attributes are
not independent.
Next example illustrates the use of this nomenclature and its notation.
Suppose a designer wants to design a pump. The pump, P , is the concept. It has various
properties e.g. ’diameter’ and ’work principle’. The latter ones are the attributes of the pump
and give rise to the variables P.diameter and P.workP rinciple. A dot (.) between two names
4 The risk of confusion is, however, rather large. If we say that ’3’ has type ’integer’, we implicitly assume that ’3’
is a value of an attribute that allows all possible integer values. For instance: if the attribute is ’number of tokens’,
and the concept to which the attribute is applied is ’playing card’, the admitted values are only 1,2,3,4,5,6,7,8,9,10.
So stating that the type of ’3’ is integer is, in that case, meaningless or at best rather unspecific. Therefore it is
always better to reserve the notion of ’type’ to attributes rather than to values.
82
Figure 4.5: In a model that serves to support design decision, variables can play four different
roles; this introduces four categories of variables.
expresses that the left thing is a concept, and the right thing is one of the attributes of that
concept. Now let’s say that the pump P is a centrifugal pump (=the work principle has value
’centrifugal’) and has a diameter of 20 cm. These (’centrifugal’, ’20 cm’) are the values of the
attributes (’work principle’, ’diameter’), respectively. These values are chosen from a set of possible
values, known as the types. This is denoted in the following way: P.diameter ∈ {10, 20, 40, 60}
and P.workP rinciple ∈ {vacuum, piston, centrif ugal, membrane}. Another attribute can be
P.f lowRate. The flow rate is related to the diameter. In that case a relation can be established
R(P.diameter, P.f lowRate). Whether this relation is a function, and if it is a function, whether
we have P.f lowRate = f (P.diameter) or conversely P.diameter = g(P.f lowRate) still remains to
be seen (although in this case, it is quite obvious that the first alternative holds).
As stated before, we will regard variables always as attributes of a concept. Therefore, ’diameter’
is not a variable, but ’P.diameter’ is. Indeed, the word ’diameter’ could refer to a large amount
of diameters in the system under consideration. By explicitly mentioning the concept to which a
diameter applies, we disambiguate.
The figure 4.5 shows how the various variables (=attributes belonging to concepts) are related.
These attributes, being variables of all four categories, and their relations together form the
model. This model expresses the values of the variables to be optimized (category II) in terms of
the remaining variables.
4.1.8
Cyclic dependencies
It is very important that the model built does not contain any cycles. If a cycle would occur, this
would mean that there is a chain of dependencies that would indicate that a variable depends on
itself. This is typically a symptom of an inconsistent model. Programs such as Excel and other
spreadsheets report an error if a cyclic dependency occurs. (Notice that, due to our definitions,
cycles can only occur inside category IV!)
It seems quite obvious that no cycles should exist, but in many design projects, a considerable
amount of time is wasted because designers do not realize that they are in fact plagued by one
83
or more cycles. Very often, the occurrence of cycles manifests itself in lengthy, non-productive
discussions that seem to go in circles. A particular nasty circumstance occurs if parts of the cycle
reside in the heads of different designers in the team. In other words, A thinks that y = f (x); B
thinks that x = g(z), and C thinks that z = h(x). Unless A, B, and C communicate explicitly
their assumptions about the dependencies f , g, and h, it can take weeks before they discover the
underlying cause of the problem. Even if it were only for avoiding these non-productive discussions,
it would be worthwhile to explicitly list the variables that make up the current model and to point
out the dependencies between the model variables. This helps to see which quantities depend on
which.
Constraints
When we incrementally construct a model, adding variables and functions while we go, we may
sooner or later encounter a cyclic dependency. Fixing the cycle by replacing functional dependencies by non-functional relations, confronts us with (a set of) simultaneous relations. Once we have
stated which variables belong in categories I and III, we know which variables are the unknowns
(namely, those in categories II and IV). Then the set of relations boils down to a set of simultaneous equations. These form the so-called constraints in our model. Notice that the constraints do
not necessarily exist between numerical variables. Non-numerical, and even non-ordinal variables
can - and will - also partake in constraints.
How to deal with constraints
For an example of handling constraints we refer to a simple design problem. Suppose we want
to manufacture a box out of a piece of copper wire with length L. The box will have height h,
width w, and we can choose between a square and hexagonal cross section (as represented by the
variable cs (=cross section)). The volume of the box will be denoted by V . Variables h, w, cs are
in category I; the volume V is in category II (it should be as large as possible). The length L is
in category III. If we decide for a rectangular box, we have 4 pieces of copper wire with length h
and 8 pieces with length w; together, they should not exceed L, so
4h + 8w ≦ L.
In case of a hexagonal box, we get
6h + 6w ≦ L.
(Verify that for a regular hexagon, the width (or the diameter) is twice the length of one side hence the term 6w!). If we want to make the volume of the box as large as possible, it is obvious
that we should use all the copper wire, so the constraints then are:
4h + 8w = L,
or
6h + 6w = L,
respectively.
The expression for the volume is
V = hw2 ,
84
or
V =
3 2√
hw 3,
8
for the rectangular and hexagonal cases, respectively.
There are three approaches to deal with constraints:
1. Refrain (abstain) from part of the design freedom
• Choose one (or more) variables that are sacrificed (category I) e.g. h. So we move h
from category I to category IV (we have not established cs yet, but since there are only
two options for cs, we can repeat the entire procedure for both options, and ultimately
pick the option that gives the best result). For h to be in category IV, we have to have a
function that expresses h in terms of remaining category-I and III variables. We obtain
this function h = f (w, cs, L) by ’turning the constraint inside out’. This can also be
formulated as: algebraically eliminating one or more category-I variables. This gives:
L − 8w
h=
4
or
L − 6w
,
h=
6
for the rectangular and hexagonal case, respectively. Then there is only one category-I
variable left (namely, w), and we have no more constraints.
• Here, h is the calculated ’sacrificed’ variable: it has been removed from category I, so
we cannot autonomously choose its value; in stead, it follows from out choice for w and
cs.
• In short: this procedure can be seen as a formal manipulation to re-write constraints in
order to eliminate category-I variables. These constraints are turned ’inside out’ into
functions that express the former category-I variables now as category-IV variables
in terms of the remaining category-I variables. This is only possible if the formal
manipulation is tractable. For instance, it cannot be applied for arbitrary non-linear
constraints, since the solutions of arbitrary equations cannot be written in closed form
- that is, in terms of a finite number of algebraic manipulations. This means that in
practical, non-trivial situation, this approach is not feasible.
2. Iterate
• We use the full design freedom, i.e. we set (arbitrary) values to all category-I variables.
• next we check the constraint; if the constraint comes in the form of a monotonic function of category-I variables, then decide whether your category-I variables should be
increased or decreased. For instance, if D = 4h + 8w − L, and we find that D > 0,
we must adjust h and/or w. We could for instance replace h by h′ = h − D/8 and
w by w′ = w − D/16. We see that 4h′ + 8w′ − L = 0, so the constraint is met. For
more constraints this trick does not work in one step, but repeating (iterating) will
sometimes converge to a set of values that meet all constraints.
• There is no guarantee that this process will converge. In fact, it requires a very subtle
analysis to see under what conditions convergence occurs. However, it doesn’t harm to
simply try if this works.
3. Using penalty functions (Lagrange multipliers) To each constraint, we associate a new
category-II variable. We focus on the case of the rectangular box; let the additional variable
(again) be D:
D = 4h + 8w − L
85
The fact that the constraint holds is equivalent to the situation where D = 0. In stead of
searching an optimum for V , we now search for an optimum for V +λD where λ is a so-called
Lagrange multiplier. The value of λ should be such that D = 0; we see that in that case,
replacing V by V + λD indeed makes no difference. In this example we use the additional
category-II variable that expresses that the surplus of wire be 0. Now we proceed as follows
(notice: this method only works in case we deal with numerical variables):
• If the model is sufficiently simple, do analytical work (otherwise, use numerical algorithms to solve the required equations), namely:
∂
V + λD = 0,
∂h
and
∂
V + λD = 0
∂w
• We differentiate and get
w2 + 4λ = 0,
2hw + 8λ = 0.
Now we can express w and h in λ:
√
w = h = −4λ.
• We find the value of λ by substituting back into the constraint equation:
r
L
.
−4λ =
12
The final result is h = w =
L
12 .
In case multiple constraints have to be dealt with, these can be added up (provided they are all
non-negative!) and be considered as if they were one constraint.
Of course, the above introduction is hardly scratching the surface of the problem area of constraint
resolution. The interested reader is referred to a vast array of text books on the topic.
Educated guesses and models
In real life the value of a certain variable is often not exactly known. In this case the designer
has to make use of educated guesses. Besides educated guesses for values, there are also educated
guesses for model relations. Indeed: it often occurs that we not only don’t know the value of a
variable, but also that we don’t know its (mathematical) behavior as function of other variables.
(Notice: this obviously applies to variables in categories IV and II). An example of an educated
model is illustrated in graph 4.6, where we model the performance of a pizza delivery courier in
number of delivered pizzas per hour. We assume that his performance depends on his salary per
hour in the following way:
• Below a certain threshold value (say, 4 euros per hour) the pizza delivery courier is not
willing to work at all.
• Above the threshold value the performance is assumed to depend in a linear way on the
salary (a ’linear’ relationship, rather than a more sophisticated one is chosen as this is the
simplest possible form, avoiding other parameters that need to be given a value).
86
Figure 4.6: Ramp functions can model simple monotonic behavior.
• Above a certain value of his salary (say, 12 euros per hour), the performance cannot be
increased anymore, because either lack of additional stimulation or inability to perform
better.
If the final result, hence the value of a category-II variable, appears to be very sensitive to certain
other variables, a more elaborate study should be made on this dependency. In such a case, one
should replace the educated model by a more accurate model, for instance obtained by market
research.
In case properties which do not have proper dimensions have to be used (such as taste), the
’values’ for the y-axis can often be normalized, e.g. to 0 - 100%. This normalization procedure,
however, always introduces a certain extent of arbitrariness. If the category-II variable depends
on multiple normalized variables, these normalized values have to be multiplied in order to obtain
a judgment on the category-II variable. Notice that it may seem that this multiplication of
normalized quantities eliminates any arbitrariness: the result is again normalized (=between 0
and 100%), and all contributing variables have a monotonous effect. This is not true, though.
Indeed, implicitly we have introduced, for every argument variable, an equal weight factor, being
the exponent (=1) to which each variable is raised before multiplying with the other variables.
Compare the two models:
r = abc
r = ab2 c
where a, b, c are all normalized between 0 and 100%. Clearly, r will also be normalized in both
cases, but in the second case, b has much more impact on the final result than in the second case.
So when proposing educated guesses for ’semi-qualitative’ models, we should be aware of the role
of these implicit weight factors. The issue of normalization, and the various choices that relate to
it, will be addressed again when we elaborate on a case example in the next chapter.
4.2. MODELING AN OPTIMIZATION: MULTIPLE CATEGORY-II VARIABLES
4.2
87
Modeling an optimization: multiple category-II variables
Optimization of mathematical models is covered thoroughly in (numerical) mathematics. However,
most approaches work for the case where there is only one function to be optimized. In our setting,
that would mean: only one category-II variable. A brute force method to ensure that there is only
one category-II variable consists of the following: suppose we have category-II variables v1 , v2 , v3 ,
· · · vn . Then we can construct a resultant category-II variabe V as
V =
n
X
wi vi
i=1
, which requires weights wi . As we discussed in chapter 1, however, the values of these weights
strongly determine which optimum will eventually be reached, whereas objectively choosing the
values of the wi to adequately represent our intuition is very difficult. In all but the most trivial
applications, the trick to replace multiple category-II variables by a single category-II variable is
therefore clearly unsatisfactory. Therefore we will study an approach that is more generic.
4.2.1
Pareto plots
Very often the number of possible solutions is tremendously large and as a consequence it is impossible to analyze them all. Furthermore, we cannot order them since, in general, there are multiple
category-II variables. Therefore we have to resort to a technique called Pareto optimization.
As a first example, assume we have 2 category-II variables, f and g (e.g. profit and safety). They
are related to a number of category-I variables, e.g:
a ∈ {a1 , · · · , am }
b ∈ {b1 , · · · , bn }
c ∈ {c1 , · · · , cp }
d ∈ {d1 , · · · , dq }.
By considering all possible combinations of the category-I variables (attributes), there are m ×
n × p × q possible designs (concepts). This can be a very large number, and we should try to find
which is the ”best”. The notion of ”best”, however, cannot be expressed in the form of a single
function of f and g. Indeed, suppose that we should decide to optimize f + g, then we might get a
different result from optimizing f + 2g. Which of these two results is ”better” can not be decided.
In stead, we have to do justice to the fact that f and g are two different and probably independent
category-II variable, and any notion of ”best” should take the various combinations of f and g
values into account. The simplest way to formulate ”best” in terms of several variables, is to deal
with a Pareto plot. A Pareto plot is used to optimize multiple, simultaneous objective variables.
A Pareto plot is constructed in the following way:
• The axes are the category-II variables. In this example, they span a 2-dimensional space (in
general, the dimension can be arbitrary);
• Because all category-II variables are related to the category-I variables, all possible designs
(=all dots in the figure below) are plotted in this space.
Now a solution X is said to dominate a solution Y if it is better in all respects. That means: the
values of both f and g for X are larger than Y ’s values for f and g. In the end only the solutions
are considered which are not being dominated. This set of solutions forms the Pareto front (in
88
Figure 4.7: The principle of Pareto-optimization.
figure 4.7, these are indicated by circles). The Pareto front does not necessarily have a convex
shape as it is in the present example. The front could also be a straight line or concave or any
other monotonous shape.
Properties of the Pareto technique:
• It helps to reduce the number of possible solutions to those that are not dominated;
• No weight functions have to be thought of by the designer, that is: designers’ subjectivity
is avoided and therefore discussions related to weight-factors can be avoided or at least
postponed.
Although the Pareto technique has significant advantages in the process of optimizing a model
for obtaining ’best’ category-I variables, there are two distinct disadvantages that should be well
understood:
• Unfortunately, the addition of an extra category-II variable does not result in a partial
collection of Pareto front solutions. So the Pareto front cannot be built up in an incremental
way. Therefore, the calculation of the Pareto front can be rather expensive: it requires, for
N candidate solutions and M category-II variables, a total of N 2 M calculations.
• The main purpose of the Pareto technique is, to reduce the collection of candidate solutions
as much as possible. The smaller the fraction of candidate solutions that are non-dominated,
the more benefit we have from the Pareto technique. Now we observe that the chance that
a solution is non-dominated increases with the number of category-II variables. Indeed, in
order to be dominated, it is necessary that a solution is better in all respects, and domination therefore will occur less frequently when the number of category-II variables increases.
For this reason, the effectivity of the Pareto technique reduces with increasing number of
category-II variables. In practice, with collections of solutions of no more than few hundreds,
the number of category-II variables should not increase, say, 4.
Once the Pareto front is constructed, and (hopefully) few solutions are left (= the solutions on the
Pareto front), it is usually necessary to go back to the client and agree on certain trade-offs that
89
have to be made. During these negotiations it may be inevitable to introduce personal preferences
to come to a final choice of design, but at least the discussions can focus on the few solutions that
are dominated - and most likely, many considerations that otherwise would consume valuable time
can stay out of the discussion.
4.2.2
Estimating a Pareto front: evolution theory
Pareto plots have been introduced already in the 19th century. However, they have recently
gained much interest in the design community since there is a strong and fruitful connection with
evolutionary design, also known as genetic design.
Evolutionary design is based on the metaphor of biological evolution. As may be known, all
observable properties of an biological individual (in our case: the concept ’the artifact-to-bedesigned’) are part of the phenotype of that individual. Therefore, the phenotype determines the
individual’s the chance of survival. The attributes of the phenotype therefore can be considered as
the category-II variables in our design case. The phenotype in turn is determined by the genotype
and the surroundings of the individual. The genotype can be considered to be the category-I
variables in our case of interest, and the surroundings are the category-III variables.
Evolution is driven by survival of the fittest, that is the best and strongest design solution(s) will
survive after a certain selection procedure. In order to do so, Pareto - genetic optimization follows
next steps, inspired by the evolution theory:
1. Create a set of individuals (e.g. 50), called a population, in a random way by choosing, for
each individual, arbitrary values for all the category-I variables.
2. The fitness of individual candidate solution X may be related to the number of individuals by
whom it is dominated. The lower the number of candidate solutions that dominate solution
X, the ’fitter’ we regard solution X. Notice that the fittest individuals are those that are not
dominated at all; that is, those on the Pareto front. The number of individuals by whom X
is dominated, is established by means of calculating the values of the category-II variables
for all individuals in the population.
3. Kill a certain percentage of the non-fit ones. Do not kill them all, since there might be some
latent strong properties, that in combination with other values for other category-I variables
- lead to fit individuals at some future generation.
4. Generate additional new individuals by:
• Random mutations;
• Crossing over: combine successful genes from two individuals (i.e., take the values of
a number of category-I variables from one successful individual and the values of the
remaining ones from another successful individual);
• Resurrect few of the ’dead’ ones: some of their attributes are given different values in
the next population and therefore it is possible that a dead solution can come out much
better with these new attribute values.
After step 4 return to step 1.
In the course of the first few generations, the Pareto front can be seen to move as a whole in
the direction of (objectively) better and better solutions. Since a new individual is identified on
the Pareto front only if it is not dominated, elements can only leave the Pareto front if they get
replaced by something better. Therefore, we make monotonous progress (even if the progress may
get slow after a number of iterations). As long as a sufficiently large percentage of the solutions
is not on the Pareto front, there is ample opportunity for mutations by means of the various
90
mechanisms, and therefore the front may continue to improve. There are at least three causes for
the front to cease improving:
• If the remaining population gets too small, that is: the majority of the solutions are on the
Pareto front, there is not enough ’livestock’ left for generating new mutants. In this case,
we might consider increasing the population, or killing some of the individuals on the Pareto
front. The latter jeopardizes the property of monotonous improvement: it is possible that,
by accident, we kill an individual that causes a ’dip’ or a ’hole’ in the Pareto front. As a
result, we might see part of the Pareto front moving ’backwards’, or deteriorating. In a more
careful approach we should ensure that an individual is taken from the Pareto front only if
there are other individuals that are sufficiently nearby to avoid deterioration of the front as
a whole.
• A second reason for the Pareto front to cease improving is, that the entire population occupies
a too narrow ’niche’ of the solution space. Although the usage of an entire population rather
than a single candidate solution should avoid to get trapped in a local optimum, the size of the
entire solution space could be soo immensely large that the used population gives insufficient
coverage. In this case, we should either increase the size of the population (at the expense
of computation time: the amount of effort to do one iteration is, obviously, proportional
to the size of the population), or increase the relative probability of random mutations, at
the expense of the mechanism of crossing over. If all new individuals would result from
random assignments of values to category-I variables (that is, random mutation), we can
achieve broad coverage of the solution space, but slow convergence, since the system won’t
benefit from fortunate interbreeding of two half-successful individuals; if all new individuals
would be the result of crossing over, we would maximally benefit from the advantages of
interbreeding, but the diversity of the population stays limited. The art of tuning a genetic
design process is, to have a good balance between the various mechanisms.
• A third reason could be, that the obtained Pareto front is a sufficiently accurate estimate
of the ’true’ Pareto front. That is: there are no new solutions that dominate the present
Pareto front (of course, under the assumption that the model is sufficiently accurate). In
this case, the process has reached its goal.
Pareto: post processing
At the end of the genetic process, we have a Pareto front that no longer improves. Stated more
accurately: the Pareto front as a whole does not move in the direction of better solutions. This
does not mean, however, that improvements of individual solutions on the Pareto front are not
possible. Indeed, a point is on the Pareto front (and therefore, will not be replaced by any other
solution) if it is not dominated. But we cannot conclude that every point on the Pareto front is
locally optimal that is: that there is no improvement possible. With a simple intervention, we
can check the local optimality of a solution on the Pareto front, and if possible ensure that it is
truly optimal.
Indeed, call the solution as it results from a completed iterative process as above, s. The values
of all the category-II variables of s are such that s is not dominated. These values are functions
of (in principle) all category-I variables. For a minute, assume that all category-I variables are
(real) numbers, and also assume that the functional dependency of s on the category-I variables
is continuous. Then we can apply, for a category-I variable v with value x, a small change to
x → x + δx, and check if solution (v = x + δx) by any chance dominates solution s(v = x). If
so, the solution with v = x + δx is a better solution than the solution with v = x, and we can
replace the value for v by the new one. If not, we try v = x − δx. If none of the two gives a new
s that dominates the old s, we can conclude that s, as far as category-I variable v is concerned,
91
is optimal: it cannot be improved5 . We repeat this process with all category-I variables, until no
further improvements can be obtained (’improvements’ in the sense that a new solution dominates
a previous one). We then have reached the situation where s is locally optimal and we remember
that in the original situation, we could not ascertain that.
After we have applied the above process to all category-II variables for all Pareto front-solutions,
with the result that some of them may attain new values, we can ascertain that further local
optimization is no longer possible6 . We have lost the guarantee, however, that the collection of
improved solutions are all non-dominated. Indeed, it is possible that a single solution (say, s1 )
has improved very much to the extent that it now dominates one of his neighbor-former-Paretocolleagues s2 that showed to be benefit from the attempted improvement. Obviously, s2 should
no longer be labelled as being on the Pareto front. So after the local optimization post process as
described above, we should do at least one further round of the Pareto-finding process to ensure
that the claimed Pareto-solutions are indeed non-dominated.
Practical experience shows that, despite the fact that there is no real evolutionary underpinning
of the idea of local improvement, the application of this post process can give a spectacular
improvement of the outcomes. Although a full post processing iteration over all Pareto solutions
typically takes an amount of calculation time that is of the order of the entire convergence process
in the first place, the obtained quality increase in general more than justifies this.
5 assuming
that δ is sufficiently small, and disregarding other numerical subtleties.
have not yet explained what to do with non-numerical category-I variables, and / or with non-continuous
dependencies. We give no exhaustive treatment of these cases here; the software system that implements these
ideas, and that is described in a subsequent chapter, uses reasonable heuristics to accommodate with these events
that perform well in practical cases, even though no mathematic guarantee for the general situation can be given.
6 We
92
Chapter 5
Modeling: a tutorial
’Even a stairway to heaven needs heavy climbing’
5.1
Generic characteristics of a functional model
Using the theory of the previous chapter, we will tackle a concrete example. We will see how
a systematic introduction of variables leads us from category II in a number of steps either to
category I or to category-III variables. At every step, we have the opportunity to think about the
assumptions and considerations that apply for the particular (functional) relation at hand. In fact,
we will only write down functional expressions that meet with a specification, stated beforehand.
First, we think about what we want to express with a particular functional relation, and next we
seek a mathematical format to capture this intention. For instance, we may have the intuition
that a quantity Z depends on X and Y , and that it is increasing with both. So we may consider
Z = X + Y , or Z = X × Y or even (assuming X and Y are both > 1), Z = X Y or Z = Y X . To
go even further, Z may be a 2-dimensional table with indices X and Y (assuming that X and Y
are both integers in a finite range) that gives, for each pair (X, Y ) the resulting value. If we don’t
have any further intuition, all these options, and many more, are acceptable. Only if we have
more knowledge about what we want to express, we can restrict the class of acceptable functional
relations. For instance, if we know that Z should behave symmetrically with respect to X and Y ,
we can rule out such functions as Z(X, Y ) = X + 3Y or Z = X Y . But for instance X 2 × Y 2 , or
a symmetrical table with values that is both increasing in X and Y would still do. To go further,
if we know that Z should be both proportional to X and to Y , we can forget Z(X, Y ) = X + Y .
But even then, expressions such as X × Y , 2X × Y and 10000X × Y are all still possible.
This way of developing a model perhaps may look strange at first. We are familiar with given
formulas from physics or economy, and all other relations follow uniquely from ’common sense’.
This may seem true for simple cases, such as ’if one chicken lays N eggs per week, M chicken lay
N × M eggs per week’, but it soon becomes problematic.
And even in the case of the chicken: it is pretty likely that the presence of other chicken affects
the egg-production behavior... Perhaps chicken are sensitive to competition, so a formula such as
93
94
CHAPTER 5. MODELING: A TUTORIAL
M × N (1 + αM ) with some small empirical constant α might be more appropriate.
In fact, every functional relation, expressed as a mathematical formula, is based on assumptions.
Even basic relations such as Ohm’s law, V = I × R for the relation between voltage, current and
resistance in an electric circuit only apply in a very limited regime, depending on temperature,
material properties, aging effects and other issues. Only in abstract mathematical contexts, assumptions may be irrelevant (for instance: the area of a rectangle with sides A and B is A × B,
and not approximately A × B), but this is only so because the quantities occurring in mathematical contexts are necessarily abstractions. A ’rectangle’, the notion of ’area’, and the notion of
a ’side’ don’t refer to anything physical. To the contrary, the area, estimated as the amount of
paint needed to cover it, of a rectangular sheet of paper for which we have measured the lengths
of its sides using a ruler will not be equal to the product of the numerical outcomes of these two
measurements - if it were only because every measurement has a finite accuracy, and therefore
should be represented by a statistical distribution rather than by a mere number.
The systematic approach to work our way through a model, starting with the category-II variables
invites us, at each step, to think about the relevant assumptions, to specify the type of behavior
that meets with our intuition or intention, and next to seek an appropriate expression for it.
We will know exactly when our model is ready: as soon as there are no ’pending’ category-IV
variables, and every category-II variable has been completely expressed as a function of something
else, and eventually in terms of category-III variables (that are measured, observed or guessed
constants), or category-I variables (that are the result of our own choices). In other words: a
model is ready as soon as the values of the category-II variables can be calculated. Of course,
this does not mean that such a model cannot (or: should not) be refined; with ’ready’ we only
mean that a model is in a stage where it can be calculated and possibly optimized. Based on the
numerical results, we can decide about the plausibility of the model: does it behave in accordance
to our intuition? Do we understand the (order of magnitude) of the results that we obtain? Also,
in this stage we can do a first check if the outcome is feasible - in the sense that the category-II
variables we hope to optimize attain values that are acceptable.
Calculations of this type are commonly performed in a spreadsheet. Indeed, spreadsheets are
convenient for specifying functional relations, provided that we adopt some discipline. In a blank
spreadsheet all cells are identical - they can all contain expressions that may link to arbitrary
other cells. As soon as we start to fill in the spreadsheet with functional expressions in arbitrary
order, the overview of the model soon will be completely lost. On the other hand, if we build the
model in accordance to the directed, acyclic graph as discussed before, and preserve the distinction
between the categories I, II, III and IV, we may safeguard ourselves against loss of control during
the process of making the model.
But apart from a spreadsheet, we soon will see that there are other means to represent a model.
Although we first give a step-by-step development of a spreadsheet version of a concrete model in
this chapter, we re-phrase the model in a more intuitive format in chapter 6. As we will see there,
this will give us further support for the process of building the model, and automated optimization.
For a start, however, we will assume that we use a standard spreadsheet program (say, Microsoft
Excel 2003). The only conventions that we will adopt, are:
• We start with category-II variables. We think what they should depend on, and we provide
an expression for the dependency. In many cases this will introduce new variables. These
can be of categories I or III; more often, however, they initially will be category IV variables;
• As long as there are category-IV variables that have not yet been expressed as functions of
category-I and III variables only, we continue ’from right to left’ with expanding the graph
from the previous chapter;
• We should think beforehand what should be done with a category-II variable: should it be
as large as possible or as low as possible - perhaps it should be positive, negative or (close
5.2. A FUNCTIONAL MODEL OF A TAXI COMPANY
95
to) zero. This will help us in thinking about the dependencies we should take into account1 ;
further, in the advanced version in chapter 6 it will guide us through the automated process
of optimization.
• For improved understandability by the user, variables should have names. Modern spreadsheet support naming as an alternative to giving cell addresses. In the version in chapter 6
we even go a step further an nearly eliminate the use of cell addresses all together.
5.2
A functional model of a taxi company
The example we study is the design of a taxi company. There is a large amount of decisions to be
taken before a taxi company can be set up (how many cars, how many chauffeurs, what type of
cars, what area, ...). Many of these can be expressed quantitatively (quantities relating to money,
distance and time); others are less clear (comfort, attractiveness, ...). There is not a single unique
way to derive a model; the model that we construct below is not necessarily better than any other,
consistent, model. We should keep in mind, however, that any possible, slightly reasonable model
is better than no model at all. Indeed: the model will help us to state explicitly the assumptions
we have made; it allows us to play with the various choice options in category-I, and it allows
extension and refinements in case the situation at hand should require more detailed analysis.
During the construction of the model, we try to be constantly aware of the assumptions we use;
every non-trivial formula will be equipped with a specification of the underlying intuition, or a
justification why it reads as it does. In every step below, we introduce one variable. As we proceed,
we will fill in a spreadsheet. The addresses of the cells, given in parentheses, are of course arbitrary
- this just gives a reasonable layout.
1. (F1) profit=(income-exp)/1000000
The most obvious category-II variable is profit. In this case, we express the profit in millions
of Euro’s. This ensures that resulting numbers are in a range between 0 and 10; since we will
be plotting graphs of the profit as a function of some choice variable in the same figure with
other category-II variables that are in the same range, the various graphs will allow easy
comparison. When defining the orders of magnitude of category-II variables, it is always a
good idea to allow for easy visual inspection of the several category-II variables in one graph.
If we state that profit=(income-expenses)/...., we express a basic economic intuition.
An underlying assumption is, that both need to be expressed as quantities of money-flow,
relating to the same period of time. This is not trivial. Book-years range from 1 January to
31 December, so whether major transactions occur just before or just after New Year can give
large but irrelevant fluctuations in the profit development over time. Accountants therefore
reckon with average profit, income and expenses, but this requires careful consideration over
the period of averaging.
2. (F2) fun=ffMe*ffmC*ffmP*10
Running a taxi company is not only about money. Most people begin to realize that work
should be rewarding also in non-financial terms. Since we want to design a ’good’ taxi
company, we should try to express the non-financial aspects also in our model. Therefore
we introduce a second category-II variable, called ’fun’. But this means that we need to
formalize our intuition about ’fun’. As a first step (or: a first assumption), we recognize
that fun is experienced by three different (groups of) people. There is fun as I experience it
1 For
instance, if we want our model to be conservative, and we need to find an upper bound of a certain variable
v (say, a risk of something disastrous happening), we may want to be more accurate in formulating effects that
increase v than effects that decrease v
96
(ffMe, ’fun for me’); fun as the customers experience it (ffmC, or ’fun for my customers’),
and fun as my chauffeurs experience it (ffmP or ’fun for my personnel’).
The step of expressing fun in terms of three ’components’ should be seen as a meaningful and
not-trivial assumption. For instance, it means that the process of modeling (and therefore
the subsequent process of optimization, and finally the process of running my taxi business)
is focused on me, my chauffeurs and my passengers. But, for instance, not on the (fun
as experienced by) other traffic and not on (the fun as experienced by) owners of public
transport organizations, et cetera. So: the realization that a particular variable x is a
function of some arguments, a, b and c immediately rises (or: could rise) the creative and
inspiring question: what else does x depend on. In the case of the egg-laying chicken: what
else determines the weekly production of eggs, other than the number of chicken and the
number of eggs per week per chicken (answer: perhaps the distance between these chicken,
the fact whether or not there is a rooster in the same chicken-run, et cetera).
Apart from the consideration about which variables a particular variable depends on, we
have to think about what form the dependency takes. If we agree that ’fun’ is a result of
’my fun’, ’the fun of my chauffeurs’, and ’the fun of my passengers’, we immediately have
some follow-up questions.
the types of the variables involved (1): How do we quantify fun? Is it a bounded or
unbounded quantity? Answer: let’s take real-valued intervals between 0 (no fun at all)
and 1 (maximal fun).
the form of the functional relation (2): What can we say about the interaction between several fun-sources? Answer: total fun should be monotonously increasing in all
fun-sources. So this could give rise, for instance, to
(a) fun=ffMe*ffmC*ffmP, or to
(b) fun=(ffMe+ffmC+ffmP)/3, or to
(c) fun=((ffMe*ffmC)+ffmP)/2 (and many other forms).
If we want to express the equal importance between my fun, the fun of my personnel,
and the fun of my customers, option 2c is unacceptable, since the resulting formula
should be symmetric in the three arguments. The main difference between 2a and 2b
is, that 2a expresses the notion of ’solidarity’. If one of the three experience no fun at
all (that is, the fun factor is 0), the total fun must be zero as well. If we appreciate the
principle of solidarity, formula 2a is to be preferred above formula 2b.
Finally, we observe the factor of 10. Since each of the factors ffMe, ffmC, and ffmP are
between 0 and 1, the total value of fun will be between 0 and 10. If we plot this in the same
graph as profit, this will give curves that allow easy comparison. This is an example of a
normalisation issue: in many cases, the same intuition can be represented by various versions
of a formula that differ only in terms of a constant factor. We know this from physical units:
arguments shall not depend on whether, e.g., lengths are expressed in millimeters or inches;
economic value shall not depend on whether dollars or Euros are used to express amounts of
money. In such cases, we only have to ensure consistency (that is, use a single unit for each
type of quantities throughout the model), and to ensure moderate numbers and reasonable
ranges of values (only in rare cases we will have to deal with, say, both light years and
nanometers). Notice, however, that normalization is equally important, but slightly more
subtle for dimensionless quantities. For instance, such quantities as efficiencies (e.g., as a
ratio of profit over investment) and aspect ratio (e.g., as the quotient of hight over width of
some shape) have no units, but they can be arbitrarily scaled (perhaps multiplied by 100 to
arrive at percentages). Such scale factors must be used with great care.
3. (H11) exp=salaries+wrOff+fuel+comm+insur
At this stage, we have 5 new variables, exp, income, ffMe, ffmC, and ffmP, and it is likely
that none of them is category-I or category-III. From a fundamental point of view, it is
97
irrelevant in which order we work to express variables in subsequent ones, as long as the
graph stays connected and acyclic. In other words: as long as every new functional relation
has an existing variable in its left hand side. Its right hand side either may contain ’old’
variables (ones that had been defined and expressed by means of functional relations earlier
on) or ’fresh’ ones (those that still need to be defined in terms of functional relations in
the future). Notice that spreadsheets deal with functional relations that contain undefined
arguments by means of various default mechanisms. An absent number is treated as zero;
an absent string is treated as the null-string. Although this is convenient in some respect,
it is rather dangerous - it encourages sloppiness in building functional models, and it could
lead to models where the evaluation is based on ’forgotten’ values.
While the model under construction develops, the chance that we will be able to re-use an
earlier variable will increase. Towards the completion of the model, we will not encounter any
new variables anymore, and all ’pending’ variables will be expressed in terms of category-III
or category-I variables, or category-IV variables that were introduced earlier on.
In terms of the graph, this means that the graph will not be a tree, but various root-paths will
merge together. A root-path here, is a sequence of contiguous variables, together describing
the dependecy of a single category-II variable on a single category-I, III or IV variable. In
the graph, a variable corresponds to a node, and a dependecy relation between one variable
and one that it depends on is indicated by a directed arc, a directed edge, or an arrow (These
terms are used indifferently) . A single node will lay on several root-paths. For instance,
the number of cars (=a variable we have not yet introduced, but it is obvious that we will
encounter it in a while) affects both the amount of money we need to pay for write-offs, and
the amount of money we will have to pay for insurance.
In this case, we choose to proceed with expressing exp - simply because it is relatively easy
to think of what constitute our expenses. This is a recurring pattern: thinking about the
functional expression for a new variable always starts with enumerating what quantities this
new variable depends on.
This is both an analytic and a synthetic process.
The analytic process starts from the given situation at hand (in this case: take an existing
taxi company and ask yourself what types of annual expenses there are). This will probably
give, as main terms: salaries (salaries), annual write-off for the fleet of cars (wrOff),
annual fuel costs (fuel), commissions to be paid for licenses (comm; in the Netherlands, taxi
companies have to have a license in order to operate in a municipal region), and insurance
(insur).
The synthetic process - which is relevant, since we are designing something: there is still
a large amount of creative variation possible! - amounts to asking oneself for alternatives.
For instance: are all these expenses necessary (e.g., could we eliminate the write-off by leasing cars rather than owning them?), or could a more profitable arrangement be made by
lumping expenses together (e.g., if we wouldn’t hire staff, but rather work with an employment agency - which would delegate the responsibility for staff insurance to the employment
agency). In other words: we could link terms such as ’write-off’, ’salaries’, and ’insurance’
to appropriate category-I variables that express possibly interesting variations in our set-up
(in this case, category-I variables such as ’do we yes or no lease cars’ and ’do we yes or
no work with employment agencies’). If the value of the hypothetical category-I variable
’doWeYesOrNoLeaseCars’ would take value ’no’, than the amounts of money spent in write
off and insurence (being category-IV) should be zero: these values depend on the value of
the variable ’doWeYesOrNoLeaseCars’.
It is not so much the issue that, at the introduction of every new variable we should try to be
complete in out inventory of all options - rather, the occasion of introducing a new variable
is a logical point in the process of developing the model to devote a minute to systematically
consider obvious (creative) alternatives to certain details in the system we are designing.
98
4. (H12) income=nrRmCpY*(fPr+avLpR*kmPr)
The term ’income’, introduced in step 1 is now looked at. What is the mechanism that
determined the annual amount of money that flows into a taxi company? As always we
answer this question by making a number of assumptions explicit.
• The only source of income consists of rides, and all rides are being paid for (an alternative would be a mechanism to have customers who subscribe to our services and only
pay subscription fees, or free rides as part of an advertisement campaign). This gives
rise to a factor nrRmCpY (or ’number of rides made by my company per year’), and
the income is proportional to this number. The choice to have the income proportional
to the number of rides seems obvious, but it could inspire to alternative mechanisms,
such as ’the more rides we make, the cheaper our kilometer-fare’- which could be an
interesting marketing campaign;
• The amount of money we earn for one ride consists of two amounts: a fixed price,
called fPr, and a variable amount which is proportional to the length of the ride and
proportional to a price per kilometer. (Again this is just a choice; many taxi companies,
for instance, apply two different tariffs: the price per kilometer for short rides is higher
than the price per kilometer for long rides). The later variable is kmPr or ’kilometer
price’. As to the length of the ride: this is of course a stochastic quantity. But since our
model is about annual averages, we interpret the formula for our income as a functional
relation between the expectation value of the length of the rides and the expectation
value of the income. So rather than writing the model as an elaborate statistical model,
we adopt some (more or less reasonable) assumptions of the statistical distribution(s)
at hand, and only relate expectation values (averages). For instance, the variable avLpR
is the average length per ride, perhaps assuming a uniform distribution of the actual
lengths of rides;
• In our model, there is no term to account for tips, nor for the charges for waiting time.
Of course, most taxi companies do charge waiting time, and it is probably a good idea
to do so. But as we observed earlier on: the first version of the model doesn’t have to
be complete: it just should be computable, and it is advisable to include what we think
are the most significant terms. So it is very well to leave out, in the first iteration, terms
that we believe are less important and to merely make a note that, time permitting, we
could revisit these later. This is the subtle art of, by means of non-calculated estimates,
distinguishing significant (’large’) terms from insignificant (’small’) terms.
5. (J18) ffmC=1-(nrReqRpY-(nrRStaff+nrROth))/nrReqRpY
Let us now turn to one of the fun-terms. We look at ffmC as introduced in step 7. Let us
assume that the fun as experienced by our (potential) customers relates (only!) to the chance
that they are served by our company. If a customer requires a ride (by our company), and
we cannot meet with her/his request, this adds to the frustration, and therefore it decreases
the fun. This suggests a formula of the form ffmC=1-’chance of a refused request’. We now
could, of course, introduce a next category-IV variable, to express the chance of a refused
request. If we expect that this variable will only occur on a single root path (that is, that
this variable won’t affect any other category-II variables), and if we think that a sufficiently
simple expression for this variable can be found, we can also give this expression right away.
So rather than introducing a variable for ’chance of a refused request’, we introduce the
expression (nrReqRpY-(nrRStaff+nrROth))/nrReqRpY.
The choice between introducing a variable that is to be expanded into an expression at a
later stage, vs. expanding this variable as an expression ’on the spot’(that is, at the instance
where it occurs), is partially made by the consideration whether or not this variable will
occur again on a different root path. A second, and perhaps more important consideration
is, however, that expanding variables ’on the spot’ into expressions, will give rise to large,
error-prone and difficult-to-debug expressions. In general, it is therefore a good idea, when
99
in doubt whether a new variable or an expression should be introduced, to choose for the
(new) variable. Variables occupy hardly any computer memory, they introduce only little
computational overhead, and they largely help improving the transparency of the entire
model.
In the current case, the expression (nrReqRpY-(nrRStaff+nrROth))/nrReqRpY contains the
new variables nrReqRpY (or ’number of requested rides per year’), which is the average annual
number of ride requests received by my company; nrRStaff (or ’number of rides staff’),
which is the average annual number of rides that are served by members of my own staff;
and nrROth (or ’number of rides others’), which is the average annual number of rides that
are done by others, but that nevertheless serve my customers.
Notice that the inclusion of nrROTh, which results from the desire to have ffmC as large as
possible, prompts for a mechanism where there is a pool of temporary employees. These
temporary employees are not on the payroll of my company, and I may have to pay them
more per hour than my regular staff, but it may be advantageous nevertheless to do so to
increase the experienced fun in my customers.
This is an example of a trade-off. It can not be estimated beforehand how large the term
nrROth should be, but our model can show us the category-II consequences of various
category-I choices in terms of profit and fun. Later, we will obtain a Pareto front of
possible solutions, which allows us to make the trade-off between profit and fun.
6. (J19) ffmP=DGET(N2:R8,R2,N9:N10) * ramp(annWages,12000,0,25000,1)
A further fun-term was fmmP, the fun as experienced by my personnel (my chauffeurs). Let
us assume that this is determined by the salary they earn and the type of car they drive. Of
course, there are numerous other mechanisms as well - and in a next iteration of the model
we may want to spend a couple of minutes to think about them systematically when we
revisit the expression for fmmP. For now it means that we should know something about the
amount of salary we intend to pay, and about our choice of cars.
As far as the happiness in dependence of the salary, we follow the same line of argumentation
we did earlier in the previous chapter, where we introduced the ramp-function. In this case
we assume the fun in dependence of the salary to be a factor between 0 (no fun at all - in other
words, chauffeurs won’t be willing to work) and 1 (maximal factor - in other words, increasing
the salary won’t make them more happy). The two argument values that determine the lower
and upper bounds of the salary interval of course are category-III variables. We could choose
to introduce them as variables indeed; for the sake of brevity, we can fill them in as constants
here. This is only allowed, though, if nothing else depends on these values. If other variables
would also depend on these values, and they would occur in several places in the model, we
could easily run the risk of inconsistencies it we would change one instance of a constant and
forget to make the same change to another instant. For this reason, it is in general better
to introduce named variables, even for category-III constants. As a rule of thumb, every
constant should occur only once in any model.
In this case we use the (imaginary) salaries of 12000 Euro/year as an absolute minimum and
25000 Euro/year as a luxurious maximum. The first argument of the ramp function is the
salary we decide to pay, annWgs or ’annual wages’. In a while, this will become a category-I
variable.
Next we consider the happiness factor that depends on the type of car.
A particular choice of car has all sorts of other consequences. The annual write-off, the
fuel consumption and the expected life time, to mention but a few, make the concept ’car’
a compound concept. In the previous chapter we introduced the notion of concepts and
attributes to deal with compound concepts. Now it is time to see how this works in practice.
The standard mechanism by means of which we represent concepts, attributes, and values
is a database table. In the case at hand, we build a table where every row is a concept;
100
2
3
4
5
6
7
8
9
10
N
carBrand
Mercedes
Opel
Buick
Chevrolet
Rolls Royce
Volkswagen
carBrand
=carType
O
catPrice
100000
30000
70000
120000
250000
35000
P
fuelCons
0.05
0.05
0.07
0.1
0.09
0.04
Q
lifeExp
4
3
5
5
8
2
R
funFact
0.5
0.3
0.8
0.8
1.0
0.1
Table 5.1: The information about the various types of cars we may want to choose from
every column is an attribute, and every cell is the value for the column-attribute, applied to
the row-concept. In MS-Excel, there are standard provisions to retrieve information from a
database table. The function DGET is very suitable to do so. It takes 3 arguments. The first
argument (here: N2:R8) is a database table (a rectangular array of cells). In this table, the
top row contains the names of the attributes. The second argument (here: R2) is the name
of the attribute for which we want to inspect the value. The third argument (here: N9:N10)
is a condition, or a query specification that states for which concept we want to inspect a
value. This condition is also a rectangular array of cells, which allows a large amount of
different query types to be formulated (including conjuncts and disjuncts of conditions). In
our case we need just the simplest form, where we give the name of one (key-)attribute and
underneath we give the value of that key attribute for the concept we want to have. In the
present case, this value is the contents of a (new) variable, carType.
In the table 5.1, we give a fragment of the worksheet ”model” with indicated row and column
addresses.
The attributes we have in this table are:
carBrand : the brand of the car. This is a key attribute, that means that two different
concepts must have two different values for the attribute ’carBrand’. As is expressed
in the query specification N9:N10, the concept that is to be chosen is the one with a
value as stored in the variable carType in its attribute ’carBrand’. So the definition
of this table, together with the query specification N9:N10 implicitly introduces a new
variable, carType. It will come as no surprise that this will be one of our category-I
variables in a while.
catPrice : the catalogue price of the car in Euro’s.
fuelCons : the fuel consumption of the car in liters per kilometer.
lifeExp : the life expectancy of the car in years.
funFact : the fun factor, scaled between 0 and 1, for instance obtained by a market survey.
Tables such as above often constitute information taken from catalogues, market surveys, or
- as in the present case - educated guesses. As far as all values in the table are constants,
they are all in category III, with the sole exception of carType. They do not have to be
constants, however. In a more sophisticated model, the cells could contain expressions. For
instance, the life expectancy of a car could be a function of the annual amount of kilometers
it drives. In that case, the cell containing this expression becomes a category-IV variable;
the constants that occur in such a formula presumably are category-III variables - unless
they in turn are expressions depending on something else.
7. (J20) ffMe=IF(where="E",1,IF(where="D",0.5,0.1))
101
The third and last fun factor as introduced in was ffMe, the fun for me (as an assumed taxi
company owner). Again, in a sophisticated model this fun factor could depend on many
features of my company; here we focus on one aspect only. We assume that it gives me
pleasure to have a company that operates in a region as large as possible. We introduce a
new variable where (which will be a category-I variable), which expresses where my company
will be active. Although I don’t want to think about the details yet, I decide that the various
sizes of this region will be represented by letters, ’A’, ’B’, ... ’E’, where ’A’ means the smallest
region considered, and ’E’ the largest one. Consequently, ’E’ should receive the largest fun
factor, ’D’ (slightly smaller than ’E’) a slightly smaller fun factor, and all the other ones a
really small fun factor.
This semi-qualitative intuition can be conveniently captured in the form a spreadsheet expressions using logical expressions. The MS-Excel function IF, which is most often used
to deal with logical expressions, takes three arguments. The first argument is a condition;
the second argument is the expression that is evaluated if the condition is true, and the
third argument is the expression that is evaluated if the condition is false. So if we want
to distinguish 3 possible conditions, we need to nest two IF’s within each other. If logical
expressions become more complicated, and/or if we want to distinguish more different cases,
it can be worthwhile to use a table construction similar as the table we introduced in step 6.
8. (H14) nrRStaff=MIN(staffCap,bStff*nrReqRpY)
In step 5 we introduced the variable nrRStaff, the average annual number of rides performed
by chauffeurs of my staff. We now choose to elaborate on this quantity. We first observe that
the number of rides cannot be larger than the annual number of rides that can be served
by our staff, staffCap. The latter variable would be the number of rides if each chauffeur
would spend all his time driving.
Further, the number of actually performed rides will depend on nrReqRpY, the average annual
number of requested rides for my company. Notice that we make use, for the second time,
of the variable nrReqRpY, but we have not yet given an expression for this variable. That is
fine, since we have a precise intentional definition of the variable. So as soon as we provide
a formal expression for this variable it will serve to make all expressions computable that
depend on it.
Also notice that, obvious as it may seem, the observation that the number of rides cannot
be larger than some factor of the value nrReqRpY is not necessarily true. In fact, there is
an underlaying assumption of a business model where the initiative of a taxi ride is purely
on the side of the customer. As long as customers don’t call us, our cars stay in the garage.
Put it in this way, alternatives easily come into mind (for instance, where we have a number
of cars on the road, chauffeurs just looking for passers-by who might consider to take a taxi
but who not yet decided to make a request to our company). This business approach would,
of course, give rise to entirely different mathematical model.
The number of rides actually performed by our staff is, on the one hand, determined by the
amount of available staff capacity; on the other hand it is determined by the amount of ride
requests we receive. But we know before hand that we cannot serve all requests. Even if
the total annual number of requests would not be bigger than the annually available staff
capacity: if they all would come in at the same time, we could handle only a very small
portion of them.
We model the number of serviceable requests as the product of nrReqRpY, or ’number of
requested rides per year’ and bStff, or ’busy staff’. The latter factor will be a number
between 0 and 1 which accounts for the fraction of rides for which there is actually a chauffeur
available at the point in time when the request comes in.
The staff capacity, which we introduce now, must be expressed as an average annual number
of rides. Indeed, we observe that the systematic process of developing the model dictates,
for every subsequent expression that we encounter, the dimensionality and the unit of the
102
newly introduced variables. If we just pay attention to every formula in turn, in the order
as they occur, we can ensure with little effort that the entire model will be dimensionally
consistent.
9. (F17) staffCap=MIN(nrStaff,nrCars)*indivCap
The variable staffCap was defined as the average annual number of rides that maximally
could be performed by our staff. A ride requires both one car and one chauffeur, hence
the occurrence of the factor MIN(nrStaff,nrCars). We emphasize that this again is an
invitation to think creatively about alternatives (such as: more cars than drivers (=a car
rental service) or more drivers than cars (such as: a service where car-owners can hire a
chauffeur). The factor indivCap is needed to convert a number of drivers into an average
number of rides per year; as we will see in step 11, this presumably will account for the
number of working hours per year and the average duration of a single ride. As is often
the case, the systematic development of a model according to the present methode will
automatically lead to ’obvious’ definitions which lead to ’obvious’ representations in the
form of mathematical formulas, each of which could serve as the starting point for creative
ramification. (’How could we arrange things otherwise?’)
10. (B5) nrStaff
The size of the staff of an organization-to-be-designed (=nrStaff), in most circumstances,
will be a category-I variable: we (as designers of the organization) can decide to hire or fire
people. Of course, there are organizations (such as those, based on volunteers) where the
size of the staff is a category-IV variable, based on the potential number of members (=a
category-III variable) and the fraction of those who are actually attracted to the organization
(=a category-IV or a category-III variable, depending on whether there is active propaganda
or not). In the simple model we are developing here, we assume it is category I.
11. (F18) indivCap=wrkHpY/avgDpR
The staff capacity, introduced in 9 depends on a factor indivCap, or ’individual capacity’,
which represents the average annual number of rides a full-time staff member can perform.
Under the assumption that all working hours are spent on driving (no administrative duties,
no idle time) this is the quotient of the number of available working hours in a year (=wrkHpY
or ’working hours per year’) and the average duration of a ride (avgDpR, or ’average duration
per ride’), measured in hours.
12. (L2) wrkHpY
The number of available working hours per year is a category-III variable, for instance
dictated by the law (in Holland: the ARBO-legislation that dictates the number of hours
employees are allowed to work).
13. (J13) avgDpR=chLR*avDlR+(1-chLR)*lIRR/iLSpd
In order to give a reasonable expression for the average duration of a taxi ride, needed
for the first time in step 11 we assume that there are two different mechanisms in order
that determine the duration. For local rides, we assume that the waiting time plus the
administrative overhead (writing a receipt for the customer) is dominant, so neither the
distance covered, nor the driving speed play a role. For inter local rides, the distance and
the speed do play a role. Therefore we introduce a factor chLR, or ’chance for a local ride’,
which will be a category-III variable. The average duration is the average of the average
duration of a local ride and the duration of an inter-local ride, weighted with chLR. For the
duration of a local ride, we have (category-III) variable, avDlR (or ’average duration of a local
ride’). For the average duration of an inter local ride we introduce a formula: lIRR/iLSpd.
The numerator is the ’(average) length of an inter local ride’, and the denominator is the
(average)’inter local speed’, in kilometers and kilometers per hour, respectively.
103
12
13
14
15
16
17
18
19
N
region
A
B
C
D
E
region
=where
O
radius
5
10
20
50
300
P
people
200000
250000
300000
500000
17000000
Q
cities
1
5
15
40
200
Table 5.2: The information about the various types of regions we may want to choose from
14. (F14) wrOff=nrCars*DGET(N2:R8,O2,N9:N10)/DGET(N2:R8,Q2,N9:N10)
In step 3, we introduced as one of the terms in our costs, the annual write-off of our fleet.
With the table as introduced in step 6, we can give a simple mathematical expression for
the write-off in dependency of the brand of car we use. It is the quotient of the catalogue
price and the life expectancy. Both are attributes in the table, so we can use the same
query-mechanism as we encountered before to access these values. Notice, again, that many
more sophisticated model relations can be (and should be!) considered, for instance where
the write-off depends on the constitution of the car: a car in good shape will have a larger
remaining value and could be written off in a longer period, et cetera. We just want to
demonstrate (again ...) that in the systematic development of the model, we automatically
encounter the stage where these considerations come into play: namely in the stage where
we expand the definition of the term wrOff.
15. (F13) salaries=staffSal+contrW
Another cost term was the term salaries, introduced in step 3. Since we already introduced
the business model in step 5 where we both work with our own staff (staffSal, or ’staff
salary’), and with contract-workers that come in in peak-hours (contrW, or ’contract wages’),
we should represent both terms here. The addition of the two, as we do in the formula
salaries=staffSal+contrW, seems obvious, but even in this simple case it is not the only
possibility. Indeed, a possible construction that comes to mind if we enforce ourselves to
think about alternatives, is one where my chauffeurs are made responsible for handling the
supernumerary rides. We pay them a (large) salary, and it is up to them to decide whether
they want to work many hours and do all the rides themselves, or to spend part of their salary
in hiring subcontractors, and enjoy a long weekend every now and then. Notice that this
alternative construction is a result from asking ourselves in which different ways the salaries
could be expressed in terms of staff salaries and payments to contract workers. Remember
that every mathematical operation just encodes an underlying story - and usually, there are
several stories that all could be told in this place.
16. (J17) comm=DGET(N12:Q17,Q12,N18:where)*municipC
A further term in the cost model, proposed in step 3, was the term comm, to be paid for
licences in every city in the covered region. So we should know how many cities there are
in the region we wish to cover, and the average annual amount to pay per city. The latter,
represented by the factor municipC will be a category-III variable (we have no influence on
it). The former has to do with our choice of the region, and similar as with cars, we will
introduce a table for regions. Indeed, just as a car, a region is a compound object containing
information that is represented in a number of attributes. So we will build a table of regions;
one of the attributes is the number of cities in the region.
The table is given in 5.2.
We have the following attributes:
104
region : the region is just a symbolic name, with values ’A’, ’B’, ’C’, ’D’, and ’E’, as
introduced earlier in step 7.
radius : this gives an indication of the size of the region. We could give the area, expressed
in km2 (a region has an area, irrespective of its shape), but we are more interested in
some characteristic distance (expressed in km). Indeed, distances relate to expected
lengths of taxi rides, and therefore indirectly to the average duration of a taxi ride.
There are many possible ways to get a value for such a characteristic distance. For
instance, we could take a map of the region and produce a large number of random
pairs of locations inside that region and measure the distance (measured along motor
ways) between these locations; when we take a sufficient amount, we get an estimate
of the average distance. A much faster, and not necessarily must worse estimate is, to
assume that the region is roughly square, and take for the radius half the square root of
the the area. Or assume that the region is circular and take the square root of the area
divided by π. For every estimate the following holds: an estimate only serves to arrive
at a first iteration of the model. Once the model is ’complete’ in the sense that the
category-II variables can be calculated as a function of the category-I and category-III
variables, we can perform a sensitivity analysis.
In a sensitivity analysis we investigate how accurate a particular model variable needs
to be. Suppose that we want to know if the applied approximation for the characteristic
distance is sufficient. We then replace the value (if it is a category-III variable) or the
expression (if it is a category-IV variable) by a different one that is equally far off (or
equally accurate), and we check how large the impact in the final category-II variables
is. Even better: we perform an optimization and we check if the optimal solution, or
the optimal solutions on the Pareto front, are significantly different. If they are, we
have reasons to do more work and try to get a more accurate estimate for the variable
or the expression at hand; if the outcome is not significantly different, we don’t have to
bother: the used approximation was accurate enough.
people : the attribute people represents the number of people in the selected region.
cities : denotes the number of cities in the region - where a ’city’ is a separate community
for which we have to pay a licence. Indeed, the interpretation (or: the definition)
of the attributes in our data models is fully determined by the use we make of these
attributes in other formulas. Since the value of the attribute cities is only used in the
context of the formula comm=DGET(N12:Q17,Q12,N18:where)*municipC, the definition
of cities in our context must be ’the number of times we have to pay for a licence’.
Observe that definitions as we use them are never supposed to be absolute or canonic:
definitions are only used in the context of the model we are building, and therefore the
only requirements are that definitions (a) are used consistently, that is: have the same
meaning in all expressions in which they occur; and (b) that they roughly meet with
our intuition.
Finally notice that the expression comm=DGET(N12:Q17,Q12,N18:where)*municipC re-uses
the variable where, that was introduced earlier in step 7. We use again the query mechanism
where in cells N18 and N19, respectively, we write the label (=attribute name) region and
underneath a (reference to the) variable that holds the value for this attribute (in our case,
the variable where).
17. (F15) fuel=nrRmCpY*avLpR*flPPl*DGET(N2:R8,P2,N9:N10)
We re-use the variables nrRmCpY and avLpR, both introduced earlier in step 4. Together with
table 5.1 to derive an expression for the costs of the consumed fuel. In order to do so, we
of course need another category-III variable, which is the fuel price in Euro per liter, flPPl
(or ’fuel price per liter’). Some assumptions (that automatically give rise to suggestions
for alternative options) are, that the total fuel consumption is proportional to the number
of kilometers, and that the fuel price is constant. An alternative option could consist of a
105
market model where a deal is made with fuel providers for consumption-dependent discounts,
or a market model where the chauffeurs are given a larger salary from which they have to
pay the fuel for their taxis (this would stimulate chauffeurs to take cheaper routes and to
adopt a driving style that is more cost-effective).
18. (F16) insur=nrCars*carIns+(nrStaff+addPers)*prsIns
The last unresolved cost term as introduced in step 3 is the average annual insurance premium, insur. Of all possible models, we adopt the simplest one, where we split the insurance
in fleet-related insurance and personnel-related insurance. For the latter we assume that we
pay both the premiums for the staff on our payroll, and for the incidental contract workers. The necessary category-IV variables nrCars and nrStaff have been introduced before.
The amount of contract workers thus far was not necessary (in step 15 we only mentioned
the amount of wages spend to contract workers, not the number of contract workers). The
variables carIns (or ’car insurance’) and prsIns (or ’personnel insurance’), as we introduce them here, define their meaning as, respectively, ’average annual insurance premium
per car’, and ’average annual insurance premium per person’. This is a rather naive first
estimate. Thinking about alternatives prompts for all sorts of constructions, like no-risk
discounts, lump-sum insurance deals or even the option to form cooperations with other taxi
companies to get a stronger negotiation position in the insurance market.
19. (J11) nrRmCpY=nrRStaff+nrROth
The average annual number of rides, performed by my company is the sum of rides performed
by my staff (nrRStaff) plus the number of rides performed by others (nrOth; that is, contract
workers). An assumption here is that one ride is completed by one chauffeur. An alternative
would be a hypothetical construction where chauffeurs each have their own region, and
chauffeurs are swapped at region borders. For a taxi company this may not be very common,
railway companies have been operating in this fashion ever since regular schedules were
introduced.
20. (L6) fPr
The fixed base price for any ride. This can either be a category-I variable (we choose to play
with this variable as part of our design space); a category-III variable (for instance, if we
take the base price the same as that of my competitors, to facilitate price comparisons for
potential customers) or a category-IV variable (for instance, if the fixed price is a function
of the chosen brand of cars - to express the intuition that customers should pay more to be
seated in a luxurious car). In the present model we have made it a category-III variable.
21. (J14) avLpR=chLR*llR+(1-chLR)*lIRR
In an earlier formula (in step 13) we expressed that the average duration of a ride was the
weighted combination of the duration of a local ride and that of an inter local ride. We also
need the average length, and we follow the same argument. So we re-use the variable chLR,
or the chance of a local ride. The variable llR, or ’length of a local ride’, is new, but the
variable lIRR, or ’length or an inter local ride’ was introduced earlier in step 13.
Notice that formulas such as avLpR=chLR*llR+(1-chLR)*lIRR and avgDpR= chLR*avDlR+
(1-chLR)*lIRR/iLSpd are no more or no less ’valid’ than the ’canonical’ formula that is
taught in elementary physics courses, lim∆t→0 ∆s = v × ∆t, or ’distance=speed × duration’.
The latter formula also requires strong assumptions, such as ’constancy’ of speed - which is an
abstract mathematical construct that requires impossible operations such as taking the limit
to infinitely small time intervals and infinitely small spatial distances, and (even worse ...) doing so for every infinitely small time interval ... In practice, statements or measurements of relations between distances and time intervals always relate to averages, and therefore formulas
such as avLpR=chLR*llR+(1-chLR)*lIRR or avgDpR=chLR*avDlR+(1-chLR)*lIRR/iLSpd
are just as ’correct’ or just as ’incorrect’ as the standard textbook formulas.
106
22. (B3) kmPr
As opposed to the fixed base price, introduced in step 20, the kilometer price is presumably
a variable we want to tweak in order to optimize the design of our taxi company. Therefore
we will make it a category-I variable.
23. (H13) nrReqRpY=nrCiR*frTC*nrRpCpY*cttmC
We introduced the average annual number of requested rides for our company, or nrReqRpY
in step 8. It is a very crucial variable, because it occurs in the root paths of many category-I
variables. Even without a quantitative model, we can understand that it determines, to a
large extent, the success or failure of our company. Let us first see what our intuition tells
us about it.
• It should increase with the number of people living in the region where we are active:
the more people there are, the more potential customers. This gives rise to the variable
nrCiR, or ’number of citizens in region’.
• It should increase with the fraction of people who ever take a taxi. Many people - for
instance, car owners or small children, won’t order taxi rides. This gives the variable
frTC, or ’fraction of (potential) taxi customers’, which is a number between 0 and 1.
It can be found by a market poll, it can be looked up in statical surveys, or (as in the
present case), it can simply be guessed.
• It should increase with the average number of taxi rides people (who happen to be
potential taxi customers) require per year. This introduces the variable nrRpCpY, or
’number of required rides per customer per year’.
• Finally, it should increase with the relative popularity of my taxi company compared
to my competitors. This introduces the variable cctmC, or ’chance that a customer
chooses my company’. This again is a chance, so a number between 0 and 1.
If any of the factors equals zero, the value of nrReqRpY is zero. Therefore, a multiplicative
model where all these variables occur as independent, multiplicative factors is the most
obvious form (although it is, as usual, not the only possibility). It is interesting to see
that each of the factors potentially could inspire to a distinct market strategy. Increasing
nrCiR relates to increasing the region where we are active; increasing frTC relates to the
popularity of taxis in general (not restricted to my company, so this could be a joined effort
with other taxi companies). Increasing the factor nrRpCpY relates to mobility in general
(not only restricted to taxi rides), so this could lead to a joined advertisement effort with
railway or bus companies. Only the last factor, cctmC accounts for the attractiveness of my
company as opposed to that of other companies. This is where price, efficiency and quality of
service come in. We will see in the sequel that, in the simplest model, all but the last factor
are beyond the influence of the designer. Therefore they are either category-III variables or
category-IV variables that depend on category-III variables only.
24. (J7) chLR
A category-III variable: the chance that a customer requires a local ride, introduced in step
13, and re-used in 21.
25. (L7) avDlR
A category-III variable: the average duration of a local ride, introduced in 13.
26. (J6) llR
A category-III variable, expressing the average length (in kilometers) of a local ride. Introduced in step 21.
107
27. (F20) lIRR=DGET(N12:Q17,radiusLabel,N18:where)
In step 21 we introduced lIRR as the length of an inter local ride. This length of course
depends on the size of the region we are operating in. Since we had a table (table 5.2)
with all information of regions, we can immediately make a query to the value of lIRR as
a function of the value of where. We use the same query mechanism that we encountered
before. Notice that this model assumption is somewhat naive. Indeed, just increasing the
size of the region where we are active does not simply mean that the inter local rides will,
on average, cover the entire, larger, region. The average distance customers want to travel
is not determined by the choice of a taxi company regarding its area of operation. Rather
we need some model about the travel profile of customers: how far, on average, does the
average taxi-passenger want to travel? On the other hand, the decision to cover a larger area
could inspire to active marketing strategies where customers are tempted to use the taxi for
longer rides (e.g., by spectacular discounts), or by collaborations with other transportation
organizations. The former Dutch train-taxi initiative is an example.
28. (N19) where=size
where is the variable that is used to query table 5.2. It contains the value of category-I
variable size.
29. (J8) iLSpd
The average speed of a car on an inter local connection, introduced in step 13. In the
simplest model this is a category-III variable. Indeed, the speed on motor ways is dictated
by law - unless we would decide that our fleet should contain rickshaws, elephants or other
slow vehicles - for instance because we specialize in scenic or otherwise authentic means for
transportation.
30. (J4) municipC
The commission we have to pay for municipal licences, introduced in step 16. A category-III
variable.
31. (F11) staffSal=annWages*nrStaff
The annual amount of salary we have to pay to our own staff, introduced in step 15. We
adopt the model that the salary of my own staff, unlike that of the contract workers, is
independent of the number of annual rides they perform. Of course, there are many variations possible that, for instance, could stimulate the initiative of my chauffeurs to attract
customers. The category-IV variable staffSal is expressed in terms of the number of staf
members (nrStaff) and the annual wages I pay to a staff member. These are both categoryI. Notice that we could have a completely different business model where I decide the amount
of money I would allocate to salary payment (=a category-I variable), and next make the
size of my staff dependent on this amount. In particular small start-up companies often use
the latter model: they decide to hire additional crafts as soon as they have enough money
to pay salaries.
32. (F12) contrW=nrROth*avgDpR*hourlyWage
In step 15 we also introduced the amount of money we had to pay to contract workers.
In a simple model we hire these from an employment agency; that means that the hourly
wages are non-negotiable (they are in category-III). So the (simplest) model reduces to a
multiplicative expression in terms of nrOth (’number of rides by other chauffeurs’, introduced
in step 19), avgDpR (’average duration per ride’, introduced in step 13), and a new variable,
hourly wage which will be a category-III variable, determined by the employment agency.
33. (J5) hourlyWage
The hourly wage for chauffeurs that are hired via an employment agency, as introduced in
step 32
108
34. (B4) nrCars
Category-I variable, expressing the number of cars in my fleet. Introduced in step 9.
35. (L3) flPPl
Category-III variable, expressing the gas price in Euros per liter. Introduced in step 17.
36. (L4) carIns
Category-III variable, expressing the average annual insurance premium for car insurance
per car. Introduced in 18.
37. (L5) prsIns
Category-III variable, expressing the average annual insurance premium for personnel insurance per person. Introduced in step 18.
38. (J3) nrRpCpY
Category-III variable, expressing the average number of taxi rides per year, required by a
potential customer. Introduced in step 23.
39. (J2) frTC Category-III variable, expressing the fraction of the inhabitants in a region who
sometimes require a taxi ride. Introduced in step 23.
40. (F19) nrCiR=DGET(N12:Q17,P12,N18:where)
The number of inhabitants living in the region of my choice is obtained from table 5.2 by
means of a standard query. The query is indexed by the variable where. The variable nrCiR
was introduced in step 23.
41. (B6) addPers
The amount of additional personnel, i.e., the chauffeurs that are not on my payroll but are
hired in an employment agency to work on contract basis. I must decide an upper limit to
this number of chauffeurs; the trade-off is that I must pay a certain amount per year on
insurance costs for these people, even if I don’t hire them. But if I have too few of these
contract workers, it could be that I cannot handle taxi ride requests in peak hours.
In our model, the associated mechanism was by means of insurance premium (the more
contract workers I deal with, the more insurance premium I have to pay); other mechanisms
could include that I have to pay the employment agency. It is a category-I variable, it was
introduced in step 18.
42. (B2) carType
The variable carType was introduced first in step 6, where it served to index the table 5.1.
The simplest way to model the choice of my fleet is to have a single category-I variable.
This represents the assumption that I operate my business with a single type of cars. More
interesting models of course should allow for a mixture of various types of cars, with each
type occurring with its own features as expressed in table 5.1. This would ask for a series of
category-I variables, namely one for each occurring type. Each of those would represent the
number of cars of that type.
43. (H19) cttmC=ramp(kmPr,0.8,0.9,2.5,0.1)
In the expression for the number of requested taxi rides per year, given in step 23, there was
a factor cttmC that expresses the chance that any given taxi ride will be performed by my
company rather than any of my competitors. In order to give an expression for cttmC, we
would therefore need to investigate all competing features. In a first model we could restrict
ourselves to a single feature, say the kilometer price. The simplest of all assumptions would
be that, the lower the kilometer prices, the more attractive my company would be. Therefore
we use a ramp function, as explained earlier. A quick market survey teaches us that, for
109
existing taxi companies, kilometer prices range between 80 Eurocents and 2.50 Euro. This
means that these values would be meaningful lower and upper borders for the domain of
my ramp function. Once I am cheaper than my cheapest colleague, I won’t attract a larger
fraction of the market by dropping my price even further (in a more sophisticated model, I
could increase the market for potential taxi rides by further price reduction, though ...). Let
us say that in that case I would attract 90% of the market (there will always be people who
are not affected by the standard market mechanisms). Similarly, once I am more expensive
than my most expensive competitor (and I don’t offer anything extraordinary with my taxi
rides), I will not loose any further market share by making my price even higher. Suppose
that this worst-case market share is 10%. This gives a simple, piecewise linear model for the
expected market share as a function of my kilometer price.
44. (B7) annWages
The category-I variable annWages, or ’annual wages’ expresses the annual salary that I pay
my permanent staff. It was introduced in the expression for the salaries, step 31, and it
influences the fun as experienced by my chauffeurs. If we would ignore its role in the funfactor of the chauffeurs, or if we would optimize the model to profit only, we expect that
the value for annWages will be minimized. This is a direct consequence from the fact that
the model then lacks the positive consequence of increasing the salary of my staff. The
inclusion of annWages in the chauffeur’s fun-factor, ffmP, is the simplest way to introduce a
trade-off in the model. A trade-off always expresses itself in multiple solutions on the Pareto
front. In the simple situation of a single trade-off, the extreme ends of the front (that is
a 1-dimensional curve, in this case) correspond to the pairs (minimal fun, maximal profit),
and (maximal fun, minimal profit). With more subtle interactions, and possibly multiple
trade-offs in a model the interpretation of a Pareto front may not be so straightforward; still,
it is often possible to identify certain parts of the Pareto front as certain global strategies
for the design at hand.
45. (H15) nrROth=MIN(othCap,bOth*(nrReqRpY-nrRStaff))
In step 5 we stated that rides could either be performed by my own personnel, or by contract workers. We introduced the term nrROth to represent the number of rides performed
by these contract workers. Now we have to give an elaboration of the term nrROth. We
first remember the expression nrRStaff=MIN(staffCap,bStff*nrReqRpY) in step 8 which
related the number of rides performed by my own staff to the number of requested and
serviceable rides, bStff*nrReqRpY and the staff capacity, staffCap. For the contract workers, we state something similar: nrROth=MIN(othCap,bOth*X). Here, X should express the
number of requested rides that come in and should be handled by contract workers. If we
assume that a ride is always handled by my own staff unless the staff is fully occupied, we
get for X the expression nrReqRpY-nrRStaff, that is: the total number of requested rides
minus the ones that are served by my own staff. The factors othCap (or ’other capacity’)
and bOth (or ’busy others’) have a similar meaning as with my own staff - we will elaborate
on them in a minute.
46. (H18) othCap=MIN(MAX(nrCars-nrStaff,0),addPers)*365*24/avgDpR
To express the value of othCap as introduced in step 45, we must realize that running taxis
is not just a matter of having chauffeurs: the chauffeurs must have something to drive in.
Therefore, unlike with my regular staff, the number of available contract workers need not
to be larger than the number of available cars - that is, the number of cars I have minus the
number of permanent staff. Remember that contract workers only come in if all my permanent staff is occupied. So all my staff members are driving a car at that moment. Only the
surplus cars can be used by the contract workers. Hence the term MAX(nrCars-nrStaff,0).
Further, according to the assumptions that were made in step 41, I cannot dispose of more
than addPers contract workers; hence the term MIN(MAX(nrCars-nrStaff,0),addPers).
Since capacity was expressed in average number of available rides per year, we multiply it
110
by 365*24 (=the number of hours per year) and divide it by avgDpR (=the average duration
per ride).
47. (H17) bStff=POISSON(nrStaff,avgRegRinTSL,TRUE)
Suppose that we would have n staff members, and on average n requests for a ride in any
given time slot. That is, requests for n simultaneous rides. At first sight it may seem that
we then can serve 100% of the requests, and 100% of the staff is occupied. This would only
be true, however, if the number of n simultaneous requests would not be an average number,
but a constant number. That is, if precisely n requests for a ride would exist at any time
point. This is of course not realistic. The requests are stochastically distributed, so there
will be times when part of the staff has nothing to do, and times where not all requests can
be fulfilled. We need a model to account for the stochastic nature of the arrival of requests.
The simplest, non-trivial model is based on the assumption that the chance of a request
coming in is uniformly distributed. That is, every time period has equal chance to receive
a request. This is naive, because calls for taxis peak, for instance, at closing hours of
pubs and theaters and during strikes in public transport, to name just a few circumstances.
Nevertheless, let us elaborate the simple model for uniformly distributed calls. Let us focus
on a time interval of length avgDpR. During any such interval, between 0 and nrStaff staff
members can be engaged in a taxi ride.
Of course, calls come in at random points in time. We assume that we make no serious
mistake, however, if we pretend that the time proceeds in discrete jumps of size avgDpR, and
all calls within such a time interval are lumped to the start of this interval. At the start
of this interval, all staff members have just completed the rides from the previous interval,
and they are all ready to take a following ride. So the average number of calls we expect in
such an interval is avgRegRinTSL=nrReqRpY/nrTSlpY, where avgRegRinTSL is the average
number of requested regular rides in a time slot (’regular’ means: handled by our own staff);
nrReqRpY is the total number of requested rides per year, and nrTSlpY is the number of
time slots per year.
The chance that the actual number of calls in a time slot is exactly equal to some number
X is given by the so called Poisson distribution:
P (X, λ) =
e−λ λX
,
X!
where λ is the expectation value of the number of calls per time slot. It is computed by the
Excel function POISSON(X,avgRegRinTSL,FALSE).
Now observe that we can handle a number of simultaneous calls of at most X=nrStaff.
The chance that the number of calls in a time slot is at most equal to nrStaff is given
by the so called cumulative Poisson distribution. This is given by the Excel function call
POISSON(nrStaff,avgRegRinTSL,TRUE). So, for a given value of nrStaff and a given value
of avgRegRinTSL, the calculated value of bStff is a number between 0 and 1. If it is 1, this
means that it is certain that we have enough staff. If it is, say, 0.9 we interpret this that in
90% of the cases we will have enough staff. In other words, when we take the entire period
of one year into account, and if we assume all time slots independent, we can serve all calls
in 90% of the time slots - in other words, we can serve 90% of the total amount of calls.
Therefore, the amount of fulfilled requests would be the same as if we would have received
90% of the requests. Therefore we model the effect of limited staff capacity by a multiplication of bStff and NrReqRpY where bStff=POISSON(nrStaff,avgRegRinTSL,TRUE) and
avgRegRinTSL is the average number requested regular rides per time slot.
48. (H16) bOth=POISSON(MIN(addPers,MAX(0,nrCars-nrStaff)),avgAddRinTSL,TRUE)
We had a second source of capacity, namely the contract workers. Since the number of
available contract workers is also limited, there is a chance that their capacity is exhausted
111
- even if it would be sufficient to handle the average demand. For this reason, also in step
45 we introduce a factor, bOth to reduce the actual demand. We apply the same reasoning
as in step 47 to elaborate bOth - with two modifications, however. As explained in step
45, we adopt the policy that contract workers are only brought in when the permanent
staff is fully occupied. So the number of required rides for which we should have a contract worker is not nrReqRpY, but it is the number of supernumerary rides - that is, those
rides that are not dealt with by our permanent staff, nrReqRpY-nrRStaff (see step 50 below). Furthermore, we can only accommodate contract workers with cars that are not in
use by the permanent staff. So, similar as in step 46, we set the available capacity equal
to MIN(addPers,MAX(0,nrCars-nrStaff)). The variable avgAddRinTSL, or ’average additional rides in a time slot’ represents the expectation value of the number of supernumerary
rides per time slot. In the sequel, we have to give expressions both for avgRegRinTSL and
avgAddRinTSL.
49. (J16) avgRegRinTSL=nrReqRpY/nrTSlpY
To be consistent with our argumentation in step 47, the number of required regular rides
per time slot, avgRegRinTSL, is the total number of required rides per year divided by the
number of time slots per year. So we introduce a new category-IV variable, nrTSlpY, or
’number of time slots per year’.
50. (J12) avgAddRinTSL=(nrReqRpY-nrRStaff)/nrTSlpY
To be consistent with our argumentation in step 48, the number of required additional rides
per time slot, avgAddRinTSL, is the total number of supernumerary rides per year divided
by the number of time slots per year. The number of supernumerary requested rides is the
total number of requested rides, nrReqRpY, minus those that are handled by the regular staff,
nrRStaff.
51. (J15) nrTSlpY=365*24/avgDpR
The number of time slots per year is the length (in hours) of a year divided by the length of
one time slot (=the duration of an average taxi ride, avgDpR).
52. (B1) size
Finally, the category-I variable size represents the size of the region we want to work in,
encoded as ’A’, ’B’, ... ’E’, as explained in step 7 and table 5.2.
If we enter the entire model in MS-Excel, and provide plausible values for the various category-I
and category-III variables, the result could look something like figure 5.1. Although this contains
all the functional dependencies we carefully developed, and therefore supports all sorts of what-if
analysis, it doesn’t invite us to explore the space of all possible designs of our taxi company.
Optimization is not immediately obvious, and the representation of the entire model as a mere
matrix of numbers and strings reveals too little of its underlying structure to be really helpful.
In the next chapter we will encounter some simple software tools that can give tremendous help
to actually put the model into work.
112
Figure 5.1: The taxi company model when entered in a spreadsheet.
Chapter 6
Modeling: tool support
’Climbing the stairway to heaven is fine, but an escalator is better’
6.1
Nano Accel: supporting the maintenance of functional
models
We ended the previous chapter with a functional model, developed using our 4-categories approach.
Such a model can conveniently be implemented in a spreadsheet, leading to something as in figure
5.1. This does not invite to actively explore the design space; it won’t help us in communicating
the model to our colleagues (nor to ourselves after a couple of weeks when we have forgotten
most of the details), and it cannot be optimized. Indeed, although spread sheet programs often
allow some forms of numerical optimization (sometimes called ’goal seeking’), this only allows to
optimize with respect to a single parameter. We want to make our design decisions in order to
take both profit, fun and staf waste into account, and standard spreadsheets cannot do this.
In this figure, we have exactly the same functional model, but we have added some provisions:
• The use of spreadsheet functionality is limited to the tables only.(In the example of chapter
5 these were the tables containing the information about cars and containing information
about regions.) This is plausible, as tables naturally fit within the spreadsheet concept. All
other dependencies are no longer put in cells. Rather, they are expressed as (functional)
relations, where the mathematical expression is used to input, edit and navigate the model.
• During the construction of the model, it will typically be not be executable most of the time.
There will be all sorts of ’dangling’ variables (that is, variables that have been introduced
as arguments in the right hand part of formulas but that have not yet been defined: that is,
they don’t yet occur as the left hand part of some other formula). Spread sheets responds to
such circumstances with a little informative error message ’No Value’, but it can be awkward
to find out which variables have not yet been defined. In NanoAccel we have, at any time,
a list of variables that only occur in right hand sides of expressions; only when this list is
empty we know that the model is ’ready’, that is: that it can be calculated.
113
114
CHAPTER 6. MODELING: TOOL SUPPORT
Figure 6.1: The taxi company model when entered in the modeling environment as provided by
NanoAccel.
6.2. MODEL MANAGER
115
• As soon as the model is ready, a number of buttons appear that allow using tools for the
manual exploration of the design space, for graphical evaluation, or for automated optimization.
• NanoAccel gives convenient support for navigating through the model: it helps to track
dependencies in both directions (that is: for a given variable X, it produces either a list of
variables on which X depends, or a list of variables that depend on X. Both lists are also
clickable, to allow fast navigation through the graph of all dependencies.
The tool NanoAccel is designed to support the maintenance of functional models. In this
chapter, we see how the NanoAccel software tool suite can assist in building, maintaining,
extending and exploring functional models in the form of figure ??.
6.2
6.2.1
Model manager
General Introduction
The NanoAccel system assumes a functional model, represented by a collection of variables,
expressions and values. All components of the system are evoked via the model manager form. This
is the central user interaction form, which embodies te most central functions of the NanoAccel
system. It is implemented as an MS EXCEL-form with associated Visual Basic macros - in
essential the same way as the Assist system as described in chapter 3. The model manager form
is launched by a macro called startModelManager Click. This macro is started either by first
clicking on this macro’s name in the macro-menu and next clicking on run, or by typing ctrl-m
from somewhere in the worksheet named ”model”.
6.2.2
Manual
Before NanoAccel can be run, the international / regional settings of Windows must be set
to ’English (UK)’. This is because the representation of floating point numbers depends on the
international setting: the decimal separator in NanoAccel complies with the British system.
The international / regional settings can be found in the configuration screen; this is can be found
in the Windows’ menu that appears when the start-button in the lower left of the screen is clicked.
Launching NanoAccel’s model manager form initiates the current model to empty. There are
no variables, and hence no functional dependencies. The form can be dragged to a convenient
location in the worksheet, where it doesn’t obstruct the view on too many cells (e.g., in the case
that tables exist in the ’model’-sheet). If one of the other tools in NanoAccel is started, the form
is made invisible, so that no interaction can take place as long as the other tool is in operation.
Also, the cells in the spreadsheet can not be edited as long as one of the tools is open. Figure 6.2
depicts a screen shot of the model manager form, when we just started to type in a model. In
this case, we first entered ’a = b + c’. After entering this, the system knows that there are three
variables (a,b, and c), and that of these three only a is defined1 .
At this point, NanoAccel will display a list with undefined variables in a list box in the lower
right part of the form (colored yellow); this list contains b and c. This list should be seen as a
reminder: in the future, we still need to give expressions or definitions for these variables. If the
1 A variable is ’defined’ means that the value of this variable can be evaluated provided that the values for all
variables on which it depends, are also defined. Therefore, a variable which does not depend on other variables is,
by definition, ’defined’. This is because of the convention that the NanoAccel system only accepts inputs of the
form <left hand part> = < right hand part >, where the left hand part is the name of a variable and the right
hand part is an expression that possibly involves other variables. In the case, for instance, were we input ’a = 1’,
the right hand part does not contain any variables, and hence the variable a is defined to be 1.
116
user clicks on a variable in this list, it will appear in the edit entry text box (see below) as a
left hand term of an expression; the user can complete this expression to give a definition for the
variable.
At the same time, NanoAccel pops up a list box with variables that only occur in the left hand
part of some entry, and not in any right hand (in this case, the variable a). This list box appears
lower left, and is colored orange. When the model is ready, this list box should only contain
the category-II variables. Indeed, these are the only ones on which no other variables depend.
During the process of developing the model, however, this list box might occasionally contain any
category-IV variable that has not yet been set as input for another (category-IV or category-II)
variable. In case a model can be calculated, that is: if it contains no syntax errors and all variables
are defined, it will be calculated. In that case the orange list box not only contains the names of
the left hand-only variables (typically, the category-II variables), but also their current values in
the form ’variable name=value’.
Finally, a third list box appears. This is the grey list box, in the middle right of the form.
This list box contains information about the dependencies of the current entry. There are two
possibilities: depending on the setting of the checkbox it can show the variables that depend on
the left hand variable of the current entry, or it can show variables that occur in the right hand
part (=the expression part) of the current entry. The latter is the default, which applies if the
check box slightly above the grey list box is not marked. So in the current example, the grey list
box contains the variables b and c. The text above the list box reads: ’variable ¡a¿ depends on’.
So we know that presently, a depends2 on b and c. The grey list box contains a line, saying ’click
here to close’. Clicking on this line makes the grey list box vanish. This is useful, since it sits
on top of the large, blue list box which merely contains all entries entered thus far. If there are
many entries, the blue list box contains a scroll bar at the right hand side, and this scroll bar gets
obscured by the grey list box if it is present.
Suppose that we next enter, as a new entry, ’b = 3 ∗ d + 1’. Indeed, b was one of the as yet
undefined variables from the yellow list box, and it was ’waiting’ to become defined. As expected,
b vanishes from the yellow list box, but immediately the new variable d is added. The orange list
box doesn’t change, and the grey list box now only contains the variable d. The blue list box
contains now both entries, ’a = b + c, and ’b = 3 ∗ d + 1’.
After we have entered these two entries, there are still undefined variables (namely, c and d), so
he model can not be calculated. For this reason there are no ’run’, ’Pareto’, or ’graph’ buttons.
(In a minute we will explain what these buttons are for).
Apart from the list boxes we have discussed now, there are two more boxes that can contain text.
These are the top most white box (a text box) which is used for entering and editing entries, and
below a second text box that is used for entering and editing comment texts that may clarify an
entry. Whenever the edit box is empty, we can start typing something; hitting the return-key
completes the entering or editing process and moves the edited entry or comment to the list of
entries in the blue list box. Entries don’t have to be accompanied by comment texts; this is highly
recommended, though. Conversely, a comment text without an accompanying entry can not be
entered to the system. Notice that comment texts appear between parenthese behind the entry
they belong to in the blue list box.
In order to edit an existing entry, it suffices either to click on the entry in the blue list box, or
to click on the variable in the left hand part of the entry in any of the three other list boxes (the
grey, the orange or the yellow list box). For convenience, entries are sorted alphabetically in the
blue list box.
Finally, there is one optional last box near the bottom of the model manager: this appears when the
debug-option is used; in that case, it contains values of variables that were flagged for debugging.
2 To be precise: a depends immediately on b and c. It might be the case that one of these depends in turn on
other variables. Such indirect dependencies are not shown.
6.2. MODEL MANAGER
117
The interaction with the features of the model manager takes place via a number of buttons,
checkboxes and scrollable list(s) in the various tools. In the sequel we describe these interactions
in more detail.
6.2.3
Controls
new
When we want to start a new model, the system needs to be initialized. All variables are removed
from the system. If an unsaved model exists, the user is asked first if this model should be saved.
Otherwise it will be lost.
load
Models can be saved to a file on disk an the can be loaded from disk. Saving and loading follows
the standard MS-Windows conventions. Clicking the load button pops up a file locator dialogue.
The extension for model files is .ac5. Before a new file is loaded, NanoAccel first checks if an
unsaved model exists; the user is given the opportunity to save this first.
Once a model is loaded, the name of the current model appears in the titel bar of the model
manager form. If an asterisk precedes the name of the file, this indicates that the model has
been changed since the last save operation. The model is written into the various list boxes. It
is checked for syntactic correctness, and if any errors were found, error messages are given. If the
model was syntactically correct, it is executed.
Notice that loading and saving only applies to the entries that make up the model. If the model
assumes some further information, such as tables in the spreadsheet ’model’, this information is not
automatically saved. The user is responsible for saving this information by saving the spreadsheet
proper.
save
Clicking the save button saves the present model.
save as
Clicking the save as button asks for a filename by means of the standard file locator dialogue and
then saves the present model under this new file name. From then on, the new name appears in
the title bar of the model manager form. If a name is given of an existing file, a warning is issued
that the existing file may be overwritten; the user is asked for an alternative name in case this is
unwanted.
edit
For minor editing, the built-in edit facilities of NanoAccel, based on editing text in the edit
entry and add or edit optional comment text boxes are just about sufficient. They provide
an intuitive integration with the other functions, such as run, Pareto, and graph. For more substantial editing, however, it is recommended to use a full-fledged text-editor, such as MS-Windows’
notepad. In order to use a Windows editor for editing an NanoAccel model description, we first
need to associate the file extension for NanoAccel model files to a text editor. For the current
version, this extension is .ac5: files ending with .ac5 are NanoAccel model files. Clicking on
the edit button instructs Windows to open the currently loaded NanoAccel model file with
whatever Windows application (such as notepad) this file is associated. Prior to opening the file,
a save instruction is executed by NanoAccel, so that the version on disc is the most recent version of the current model file. Next the Windows application associated with NanoAccel model
files is launched, with the current NanoAccel model file loaded. Within the opened editor, all
edit functions are available, so the file can be edited. The format of a NanoAccel model file is a
standard ASCII-text file. It consists of linefeed-separated lines. Any line is interpreted as either
an instruction line (that is, a line containing an=-sign) or a comment line (that is, a line preceded
118
Figure 6.2: A screen shot of the NanoAccel model manager.
6.2. MODEL MANAGER
119
by two adjacent slashes. Blank characters (such as spaces or tabs) may precede both types of
lines. Any other type of line is ignored. An instruction line may be followed by zero or more
comment lines; in case there are multiple comment lines, these are concatenated to a single line
when read into NanoAccel. Comment lines are assumed to belong to the instruction line that
immediately precedes them. The first line in a NanoAccel model file must be an instruction line.
After having edited a NanoAccel model file by means of a Windows text editor, the file should
be saved and the editor should be closed; next, the (updated version of the) file is automatically
loaded again in the model manager form.
check box ’V’
When using the built-in functions to edit the NanoAccel model, we use the text boxes edit
entry and add or edit optional comment. After text in any of these boxes has been changed,
and the modification should become permanent, the green ’V’ button should be clicked (compare
acknowledging editing a cell in MS-Excel). The green ’V’ normally appears as soon as changes in
any of the text boxes edit entry or add or edit optional comment occur; if the green ’V’ is
not visible, press ’return’ with the current focus inside the edit entry text box.
edit entry
The text box underneath the label edit entry is the text box where editing entries occur. In he
sequel this will be called the ’edit box’. The following applies to editing:
• All spaces in an entry are redundant, and are removed automatically, except for spaces that
occur between pairs of subsequent single quotes (’ ... ’). Pairs of subsequent single quotes
denote a textual constant (see below), and textual constants may contain spaces.
• All entries have the form ’<variable>=<expression>’. The ’<variable>’ is an identifier,
that is a string of letters, digits and/or underscores that does not start with a digit. A
variable can also be of the form @<cell address>, where a cell address is for instance a1,
cf 358, et cetera. A cell address refers to a location in the spreadsheet; as we explain below,
in this way the NanoAccel model can interface to a standard spreadsheet. Every variable
can only occur once as left hand part in an entry. Entering an entry with a variable name
that occurred earlier as a left hand part overwrites the earlier expression without warning.
• Variables are not case sensitive. The variable name ’AaaaAA’ denotes the same variable
as ’aAAAaa’. To avoid confusion, however, variable names that only differ in upper- or
lowercase are converted to the same spelling.
• The type of a variable is not explicitly given; it is deduced from the context. Variables come
in 3 types: numeric (implemented as double precision numbers), textual (implemented as
variable length strings), and boolean. For each of the three types we can have constants.
A numeric constant is an integer number (such as 34, -1435), a number with a decimal
point (such as 3.1415, -0.111, 0.000005), or a number with exponential notation (such as
-0.1 E+02 or 3.555 E-07). A textual constant is delimited by single quotes, such as ’aaaa’,
or ’peanutButter’. Also ’3.1415’ is a textual constant. A boolean constant is the word true
or false, without quotes. In case a value is not given as a constant, the type is deduced
from the form of the expression in an entry. For instance, in a = Sin(b + c), all a, b and
c are numerical variables. In x = (p > 3)&&(q < 5), we have that p and q are numeric
variables whereas x is a boolean. The operator && denotes the logical ’and’, as we will
see in a minute. In some cases the type of a variable can not be uniquely determined from
inspecting the expression. For instance, to tell if in m = M in(m1, m2) m has a numerical
value or a textual value, we need to know the types of m1 and m2. If these both evaluate
to numerical values, the function M in() returns the smallest of the two numbers. If they
are both textual, the lexicographical lesser of the two textual values is returned. If they
are different booleans, false is returned, due to the convention that false<true. In the case
120
of mixed types, the result is not determined and such usage of Min() should be avoided3 .
item Expression such as ’a-b+c’ are ambiguous: it can mean a-(b+c) or (a-b)+c. Although
NanoAccel has built-in conventions for the order of execution of expressions containing
multiple operators, it is advisable to use parentheses to disambiguate.
• In order to communicate with a spreadsheet, for instance to get access to tables, variables
may have the form of an at-symbol (@) followed by a standard Excel cell address. Such a
variable refers to a cell: if it occurs in a right hand part of an entry, the value of the indicated
cell is taken; if it occurs in the left hand part of an entry, the value of the evaluated right
hand side is copied into that cell. In this way we have the entire spreadsheet functionality
to our disposal, including functions that are not supported directly by NanoAccel, such
as spreadsheet table access and arbitrary user-written functions.
• The expression part of an entry s can contain any well-formed arithmetic string of operators
+, −, ∗ and / that operate on variables or constants. Parentheses are used to control
the order of operations. A fair number of logic operations is supported, namely: == to test
equality, and ! = to test inequality; < and > to compare magnitudes. Unary operators are
the ’-’ for numerical values and ˜ (tilde) for logical values. The logical ’and’ is given by &&
and the logical ’or’ by ||.
• Expressions may also contain functions. Built-in functions are the following:
– Arithmetic
∗ Add(), Subtract(), Multiply(), Divide() that are identical to the infix operations
+, −, ∗, / ;
∗ Mod() that computes the modulo of two numbers
∗ Abs() that computes the absolute value
∗ -() which is the same as the unary minus (so, obviously, −(5) = −5 )
– Transcendental
∗ Sin(), Cos(), Tan(), Exp(), Log(), Sqr() that are the standard functions from elementary calculus
∗ Pow() that calculates a (non-negative) number to any integer or non-integer power.
– Conditional
∗ If() takes three arguments. The first one has to be a boolean argument (that is, it
must be true or false). If it is true, If() returns the second argument, otherwise it
returns the third argument.
∗ Min() and Max() each take two arguments and return, respectively, the smaller
and he larger of the two. Notice: arguments may be both numerical or textual; in
the latter case, lexicographical ordering is applied.
∗ == () is the same as the infix-operator ==: it returns true if the two arguments
(either numerical or textual) are equal
∗ ! = () is the same as the infix-operator ! =: it returns true if the two arguments
(either numerical or textual) are unequal
∗ > () is the same as the infix operator >: it returns true if the first argument is
larger than the second (numerically or lexicographically). Similar for < ()
∗ &&() is the same as the infix operator &&: it returns true if and only if both
arguments are true
∗ ||() is the same as the infix operator ||: it returns true if at least one of the two
arguments is true
3 The latter property of the function Min() is an immediate result of the implementation in terms of built-in
VBA functions. For reasons of efficiency, the NanoAccel system relies for its runtime type-checking entirely on
the type checking system of VBA. Although this offers a significant gain in runtime efficiency and gives a relatively
simple implementation, some peculiarities had to be taken for granted.
6.2. MODEL MANAGER
121
∗ ˜() is the same as the prefix operator ˜: it returns true if its argument is false and
conversely.
– Special
∗ Sheet() can take arbitrary many arguments, and it will return the last one in the
list. This is necessary to have models depend on spreadsheets. Indeed, if a cell, say
X in a spreadsheet depends on other cells, say Y and Z it only assumes its correct
value if all the cells on which it depends also assume their correct value. In the
functional model, however, there is no control over the order in which calculations
take place. It could very well happen that the value of X is inspected before the
values of Y and Z have been set. To avoid incorrect results in such as case, we
use the function Sheet(). If we set a = Sheet(Y, Z, X), where X, Y , and Z are
cells, we enforce that first all arguments of the function are calculated (and, since
they are cells, that their values are copied into the spreadsheet), before the actual
function ’Sheet()’ is evaluated. The latter only returns the value of cell X, but at
least we are certain that Y and Z have propagated their (correct) values through
he spreadsheet.
∗ Sel() is a function that is used to denote category-I variables. As we remember, a category-I variable expresses a free choice or selection on the side of the
designer. We assume that a selection is always taken from a closed - that is: enumerable - set. We distinguish 4 types of sets. These are: integers, reals4 , sequences
and enumeration types. Integers and reals are defined by an interval, given by
a lower and an upper bound. A sequence is a series of (floating point) numbers
between a lower and an upper bound with a given step size. The step size argument must be given after the lower and upper bounds. An example of a sequence
is {0, 2.5, 5, 7.5, 10, 12.5, 15}, which is produced with the function definition
x=Sel(’mySequence’,5,’S’,0,15,2.5) . An enumeration type can be used to denote
any list of (text-)strings. An example of an enumeration type, which denotes a selection of auto brands, would be ’volkswagen,opel,chevrolet,buick,rolls,renault’. So
the entire set is encoded as a single string. If we want to construct an enumeration
type that should return a numerical value rather than a string value, we can use
the conversion function Cdbl() (see below) to turn an element of an enumeration
type into a number, for instance for the following enumeration type ’1, 3, 10, 30,
100, 300, 1000, 3000, 10000, 30000’. Finally, a selection always comes with a default value, in order to allow for an evaluation of the Sel()-function. This default
value is returned unless we are in one of the three special tools (the Pareto tool,
the run-tool or the graph-tool. These tools are discussed in a minute). This gives
for instance the following examples of the Sel()-function:
· a=Sel(’mySelector’,3,’I’,1,100) introduces a selector with name ’mySelector’.
The default return value is 3; it is an integer type (indicated by the ’I’), and
the range is all integers between 1 and 100.
· p=Sel(’diameter’,2.45,’R’,2.10,4.10) introduces a selector with name ’diameter’.
The default return value is 2.45; it is a real type (indicated by the ’R’), and
the range is ’all’ reals between 2.10 and 4.10.
· x=Sel(’mySequence’,5,’S’,0,100,5) introduces a selector with name ’mySequence’.
The default return value is 5; it is a real type which can return values 0, 5, 10,
15, 20, ..., 100 (this is indicated by the ’S’ from ’sequence’). Notice: even if the
indicated default value would not be in the range of values from the sequence,
it will be returned by default. It will not be used in the case of the Pareto- or
run-tools.
4 Technically speaking, reals do not form an enumerable set. There is no algorithm to enumerate reals. Still, for
the computer representation of numbers this should not overly bother us. By ’reals’ we simply mean numbers that
are represented by digits before and/or after a decimal point and optionally an exponent of 10. So examples of our
’reals’ are 3, 17.1, -999.999 and 2.345 E-03.
122
Figure 6.3: A ramp function
· carBrand=Sel(’carsFromTheCatalogue’,’opel’,’E’,’opel, renault, buick, chevrolet, volkswagen, mercedes, rolls’) introduces a selector with name ’carsFromTheCatalogue’, default ’opel’, and range of return values ’opel’, ... ,’rolls’. The
fact that it is an enumeration type is indicated by the ’E’.
The (named) selector is the device by means of which NanoAccel interfaces between the function evaluations and the mechanisms to explore the solution space
such as the Pareto- and run- mechanisms. For the function evaluation, the function
Sel() is just a function as all other functions, that returns a value in dependence
of its arguments when being called; for the Pareto- and run-mechanisms, selectors
allow a way to externally set values to variables. We will come back to the selectors
when we discuss the Pareto- and run-mechanisms.
∗ Ramp()serves to specify a dependency as explained in 4, for modeling situations
such as described in figure 6.3. For any value x, the function Ramp(x, xmin, ymin,
xmax, ymax) returns ymin if x < xmin; it returns ymax if x > xmax; if x <=
xmax and x >= xmin, it returns (x − xmin) ∗ (ymax − ymin)/(xmax − xmin) +
ymin. It is necessary that xmax > xmin; there are no restrictions on the ordering
of ymin and ymax.
∗ Round() serves to reduce the number of decimals of a (non-integer) number. It
takes two arguments; the second argument is the number of decimals to which the
first argument should be rounded.
∗ Debug() provides an easy means to produce printed output. It occurs, for instance,
in the following form: p = Debug(a,′ comment′ ). The value of the expression a is
printed in a textbox in the lower part of either the Model manager form or the
Run tool, preceded by a rank number (1,2,3,...) and by the string ’comment’. If no
instances of the debug-function appear in the model, this textbox is not shown. The
comment-string serves to distinguish several debug-statements. Indeed, multiple
instances of the debug-function can occur in a model (it may require scrolling
through the textbox to see them all). The function returns the value of expression
a, so p will be made equal to a. In practice it is temporarily used to check if the
value of an expression that is to be assigned to some variable has the correct or
expected value.
– Text
6.2. MODEL MANAGER
123
∗ Lower() converts a textual argument to an all-lowercase version. So Lower(’PoTaTo’)
= ’potato’.
∗ Caps() converts a textual argument to an all-caps version. So Caps(’PoTaTo’) =
’POTATO’.
∗ Left() takes the left hand substring of indicated length. So Left(’aaabbbcccddd’,3)
= ’aaa’.
∗ Right() takes the right hand substring of indicated length. So Right(’aaabbbcccddd’,5)
= ’ccddd’.
∗ Mid() takes the middle part of a textual argument, beginning at the location indicated by the second argument, with length indicated by the third argument. So
Mid(’aaabbbcccddd’,3,5) = ’abbbc’.
∗ Instr() returns the beginning location of the string, indicated by the third argument, as substring of the string, indicated by the second argument, starting at
the location that is indicated by the first argument. If the substring does not
occur, a value 0 is returned. So Instr(1,’aaabbbcccddd’,’bcccd’)=6, whereas Instr(1,’aaabbbcccddd’,’xxyy’)=0.
∗ Len() produces the length of the string argument. So Len(’aaabbbcccddd’)=12.
∗ Concat() is used to concatenate its two string arguments into one. So Concat(’aaabbb’,’cccddd’) = ’aaabbbcccddd’.
– Conversion
∗ Cstr() takes an argument of whatever type and converts it to a textual type (=a
string). So Cstr(’potato’)=’potato’, Cstr(12)=’12’, and Cstr(true)=’true’.
∗ Cint() takes an argument of whatever type and attempts to convert it to an
integer. So Cint(’14’) = 14, and Cint(’-123’)= -123. But Cint(’potato’) and
Cint(’12.675E+43’) both produce an error; in the first case because there is no
numerical interpretation of ’potato’; in the second case because of an overflow.
∗ Cdbl() takes an argument of whatever type and attempts to convert it to a double precision real number. So Cdbl(12) and Cdbl(’12’) both produce 12.0, but
Cdbl(’potato’) produces an error.
– Statistical and combinatorial
∗ Poisson() takes three arguments. The first two are numbers, say x and λ. If the
third argument is false it produces the probability density that a random uniform
process with an expectation value λ events per unit time produces, in a certain
time interval of unit length, precisely x events. This probability density is given
−λ x
by the formula e x!λ . If the third argument is true it computes the cumulative
probability, that is the chance that the number of events in a given unit time
interval is at most x when the expectancy rate is λ arrivals per time interval. This
Px
−λ k
is the summation k=0 e k!λ .
k!
∗ Bin() is the binomial coefficient. So Bin(k,m)= m!(k−m)!
, in other words: the number of different ways in which we can take m elements from a set of k. Another
view to Bin() is the m-th number in the k-th row of Pascal’s triangle.
∗ Fac() is the factorial function. So Fac(1)=1, and Fac(n)=nFac(n − 1).
add or edit optional comment
To clarify the meaning of an entry, it is recommended to add a line of comment. The text box
underneath the label add or edit optional comment is available for this purpose. In the blue
list box, comment texts are put behind the entry they belong to between parentheses. Comments
are ignored by the model manager of NanoAccel. Other tools can take advantage of some
specific forms of comment, though. For instance, the Pareto manager (to be explained in more
detail in a minute) needs to know what it should do with any category-II variable: should it be
124
maximized, minimized or ignored - or should it be used as a constraint to restrict solutions to
those that are larger than 0, less than 0 or near 0. Normally the Pareto tool will pop up a dialogue
box to get this information from the user. To prevent this dialogue, we can put one of the words
MAX, MIN, IGN, LS0, Gr0 or NR0 between square brackets somewhere in the comment string;
this word will be interpreted as an instruction for the Pareto tool. Similarly, it needs to know if
a category-II variable should be plot horizontally or vertically in the Pareto plot, or if it should
not be plotted. To this aim, we can put one of the words HOR, VER or NONE, also between the
same square brackets. This is only useful for category-II variables. So a category-II variable with
[ MAX HOR ] as part of the comment text will be maximized by the Pareto tool, and it will be
plotted horizontally in the Pareto plot.
delete
The delete button is only visible if there is some entry in the edit box. If the delete button is
clicked, this entry is removed from the list of entries in the blue text box.
pareto, run, graph
The NanoAccel system contains the model manager and three additional tools. These are:
• run (see section 6.3)
• pareto (see section 6.4)
• graph (see section 6.5)
Each tool is launched by clicking on the associated buttons. The pareto tool serves to do genetic
Pareto optimizations (see section 6.4). The run tool allows interactive exploration of the solution
space (=the space spanned by the ranges of values for the category-I variables, or rather by
the values for the selectors that are associated to these variables. The graph tool allows visual
inspection of a dependency between any two variables.
list of entries
The blue list box contains all entries that together form the present model. Clicking on one of the
entries copies this entry into the edit box. Entries in the blue list box are lexicographically sorted.
variable [...] depends on or variable [... ] occurs in
The grey list box contains the variables onto which the variable in the left hand part of the
presently edited entry depends (that is, all variables that occur in the expression in the right hand
part of the presently edited entry),
or:
the grey list box contains the variables that depend on the variable in the left hand part of the
currently edited entry.
Which of the two cases applies is determined by the check box. Marking or un-marking this check
box allows for simple and intuitive navigation ’up’ or ’down’ through the subsequent dependencies
of the model - more or less comparable with the left and right arrow buttons in an Internet browser
that support moving from and back in the browse history. If the grey list box contains no variables
(either because the variable in the presently edited entry doesn’t depend on anything, or because
nothing depends on it) this is indicated in the text label near the check box, and the grey list box
vanishes. At any time, we can make the grey list box vanish by clicking on the entry ’click here
to close’.
Clicking on one of the variables from the grey list box, copies the entry for which this variable is
the left hand part to the edit box.
only in left hand part
6.3. NAVIGATION: THE RUN-TOOL
125
The lower left orange list box contains the variables that only occur in left hand parts of entries. If
the model is ’ready’, these are the category-II variables. If the model contains no errors, and it can
be successfully executed, the values of these variables are printed next to their names. Clicking
on a variable in the orange list box copies the entry for which this variable occurs in the left hand
part to the edit box.
only in right hand part
The lower right yellow list box contains variables that only contain in a right hand part of some
entry / entries. These variables are as yet undefined; as long as there are any undefined variables,
the model cannot be executed. Clicking on a variable in the yellow list box copies that variable,
followed by an equal-sign, ’=’, to the edit box. A dummy-comment line is entered in the comment box. If there are no undefined variables, that is: if the model is ’ready’, the yellow list box
will vanish.
6.3
6.3.1
Navigation: the run-tool
Once a model is developed, we want to find values for the category-I variables such that the
resulting category-II values are, in some sense, good. Of course we can repeatedly substitute
new values for the defaults in the various Sel()-functions,and inspect the resulting values for the
category-II variables in the orange list box, but this is an arduous task. It is difficult in this way
to develop some ’feeling’ as to the actual behavior of the model. To facilitate the exploration of
the solution space in a more intuitive, interactive way, we provide the user with an automated
user interface and logging facilities. This user interface consists of a set of sliders; one slider is
associated to each of the selection controllers, and the slider is identified with the name of that
controller. Notice that it is possible to have two or more variables to be coupled to the same
selection controller name - in other words, several instances of the Sel()-function may use the
same selection controller name. This is at best confusing, though; also, non-predictable behavior
can result if the types and/or the range definitions of the various instances would be different.
Therefore, from now on we assume that selection controller names are unique, and to a single
selection controller name belongs a single (category-I) variable. In that sense we can associate,
one-to-one a slider to a category-I variable. In real time, the setting of such a slider determines
the value of that value. For numerical values it is obvious that shifting the slider increases or
decreases the value within the borders of the interval that were set when the Sel()-function was
written down; also for enumeration types, however, we implement this behavior. Suppose that an
enumeration type contains, say, six values. Then the slider interval is divided in six intervals of
equal lengths; if the slider is in the subsequent intervals, the subsequent values of the enumeration
type are chosen. Just as with numerical values, the chosen value is printed next to the slider for
easier reference. In this way, to stick with the taxi company-example, we have a slider that allows
us to choose between car brands.
Operating the sliders takes place in real-time. This means that constantly the model is executed,
and every instance the most recent values for the selection controllers (=the sliders) is taken into
account. This means also that we can plot graphs of the time-varying values of the category-II
variables: we see changes at the instances where we move the sliders. In this way we can tune
sliders interactively to find optimal (either locally maximal or locally minimal) values for the
category-II variables. If we find an interesting setting, we can store this setting (and associate a
name to the setting for easier later reference). This will be necessary if the number of category-I
variables is larger than, say, 3: the number of possibilities to set the sliders for, say, a 7-dimensional
solution space is huge, and we will soon loose our way if we don’t apply such memory-aids.
126
Figure 6.4: A screen shot of the NanoAccel interactive run-tool.
6.3.2
Manual
The run-tool consists of two components: one is the form which contains a number of sliders (one
slider for every selection controller, that is: for every distinct name of a selection controller that
was encountered in the Sel()-functions); the second is a life updated graph of time-varying values
of category-II variables as they change as a consequence of moving the sliders. See figure 6.4 for
a screen shot.
6.3.3
Controls
sliders
The life updated graph contains one curve for each of the category-II variables. The names and
associated colors of these variables are listed in the graph’s legenda box.
The control frame contains sliders, one for each selection controller. Sliders can be operated
real-time; the effect can be visually inspected in the life updated graphs.
the log-button
The button ’log’ stores the present setting of the sliders in a list; every entry of the list is labeled
6.4. OPTIMIZATION: THE PARETO TOOL
127
with a name or comment field. The user is asked for this name at the moment of logging by
means of an interactive dialogue. The logged names appear in temporal order in the list box
underneath the sliders. One entry is always present, this is the entry labeled ’initial values’. This
corresponds to the settings of the sliders, taken from the defaults in the Sel()-functions. When
the ’log’-button is pressed, the life-updated graph temporarily stops. This gives the opportunity
to study the graphs more easily; also, when the graphs are frozen, it is easier to scroll through the
debug textbox if necessary. The caption of the button changes to ’run’. If it is pressed again, the
life updated graphs resume scrolling again, and the caption changes back to ’log’.
the list of logged settings
Clicking on an entry in the list of logged names restores the settings of the sliders of that logged
setting. Moreover, the corresponding set of defaults is transferred back to the model: the entries
containing the Sel()-calls are actually adjusted to incorporate the new values as defaults.
Notice that a list of logged settings is cleared after the form of the run-tool is closed: there is no
way to go back to a setting from a previous list of logged settings unless the settings are memorized
and copied ’by hand’.
6.4
6.4.1
Optimization: the Pareto tool
Multi-objective optimization of non-linear models with mixed types of input variables (integers,
reals and nominal values or strings), where constraints could apply, is an extremely challenging
problem in applied mathematics. There is, to date, no unified, generic approach that applies to the
broad class of all such optimization problems, and it is likely that none will be found in the future.
Huge efforts have been spent to develop algorithms to tackle all sorts of sub-classes of problems.
Presently, many sophisticated codes exist, but each is designed to handle a particular sub-class. In
some sub-classes, problem sizes (in terms of the number of variables) may be huge, and provably
optimal solutions are obtained in acceptable time (for instance: linear and quadratic programming). In other sub-classes, even small-size problems cause immense computational problems (for
instance: high-degree polynomial equations with integer variables), and there is no guarantee that
a solution is found that is anywhere near optimal or complete.
In any case, the optimal5 or complete6 solution of optimization problems requires a large amount
of specialized knowledge and expertise. It is difficult and subtle to choose the right approach given
the characteristics of the problem at hand. An apparently marginal modification of a problem can
make the difference between real-time solvable and fully intractable. Unfortunately, experience
shows that the chance that an optimization problem becomes intractable increases with its realism.
It seems that the only tractable optimization problems are highly simplified versions of the ’real’
problem at hand.
The intended context for NanoAccel is: early stages in decision making, where choices between
solution architectures are being made, and a rough, order-of-magnitude estimate for the various
parameters is required. This is spectacularly different from the highly specialized context in which
dedicated, state-of-the-art optimizing software packages were developed. It is assumed that users
of the NanoAccel tool suite are designers and decision makers, not mathematicians. This means
that a NanoAccel model will be set up with its functional behavior in mind, rather than its
mathematical properties. In case a functional expression was sought to represent a particular
behavior, the choice will be mainly inspired by qualitative intuition, and not so much by formal
arguments. For instance, the intuition of monotonic behavior with saturation is nicely captured
5 Optimal
means that no ’better’ solution exists, with some appropriate interpretation of ’better’.
means that no other solutions exist than those found by the algorithm.
6 Complete
128
with the ramp function we introduced before. A similar behavior, however, could be obtained by
an arctan function (and by many other mathematical forms). For the sake of modeling, that is:
for the average NanoAccel user, the difference between the two is irrelevant. They both capture
the same intuition. On the other hand, the difference from a mathematical point of view is huge.
The ramp function is a piecewise linear function; the arctan is a transcendental function. The
former complies with the assumptions of linear programming; the latter is a serious challenge even
to iterative non-linear solvers. On the other hand, the ramp function cannot be differentiated,
which can be a problem to local search algorithms; the arctan function is infinitely differentiable
which makes it ideally suited for such approaches. If a model would contain both a piecewise
linear ramp function and an arctan function, it would be impossible to find a single mathematical
tool to optimally deal with the model as a whole - but the average NanoAccel user might not
care - (s)he might not even realize this. More importantly: (s)he should not realize this; (s)he
should not have to bother about these intricacies. To capture the essence, and to understand the
behavior of an intricate set of dependencies is difficult enough without having to worry about the
mathematical consequences of the interplay of various components of the model.
For this reason, the kernel of the NanoAccel optimization component is designed to be as generic
and robust as possible. Efficiency, completeness and accuracy have been deliberately sacrificed.
It was considered vital that NanoAccel produces reasonable, plausible solutions that only need
to successfully compete with the obvious alternative, which is: having no automated optimization
algorithm at all.
Indeed, once a functional model exists, we can substitute, by hand values for category-I variables.
We can manually explore the solution space, keeping track of ’good’ solutions. But even if we
would do this carefully, meticulously logging our trials (for instance using the logging-facility of
the run-tool), we would find that we can visit only a negligible sub-set of the solution space. We
would soon give up, without even the slightest idea of the order of magnitude of the attainable
results in terms of category-II variables. We could easily be off with factors of 1000 or more
from the ’best’ values of category-II variables. We might erroneously conclude that a solution
architecture is not at all feasible, whereas it would be feasible if we would have investigated a
slightly different sector of the design space.
This is where the optimization component of NanoAccel comes in. Since it uses a genetic
paradigm, it is reasonably good in stochastically sampling a large part of the solution space
without loosing too much time in an exhaustive search. In particular if the dependency of categoryII variables on category-I variables is relatively smooth (that is, there are not too many isolated
’niches’ of locally optimal solutions that are very different from each other), a stochastic, genetic
approach is a reasonable choice. Compared to a manual approach, it is capable of checking a
between a factor of 100 - 1000 solutions per time interval more. It is robust in the sense that it
works for all types of models. There are no constraints with respect to the form of the expressions
(linear or non-linear, continuous or discrete) nor the type of variables (integer, real, nominal or
mixed types). It is capable to deal with constraints (reducing the set of Pareto-front solutions,
for instance, in the presence of greater than 0, or less than 0, or near 0 constraints). Finally, it
can cope with arbitrary numbers of category-II variables. If we monitor the evolutionary process
while it proceeds, we get a qualitative idea of the convergence. By inspecting the Pareto front
while it develops, we can soon see if much progress can be expected, or if convergence is near.
It should be realized, however, that
• The evolving population is only a stochastically sampled subset from the solution space.
There is therefore no guarantee that the Pareto front is complete. In other words, there
could be (many) solutions that are equally good (that is, that are non-dominated), but that
are not present in the Pareto front. In other words, the solution is not complete;
• The solutions that form the Pareto front are not necessarily optimal. We only know that
they are non-dominated by other solutions of the evolving population. In other words, it is
129
possible that, for a given solution S on the Pareto front, an other set of values for category-I
variables can be found that yields a point S ′ in the category-II space, where S ′ dominates
the present solution S.
In the sequel, we describe the controls and their function to steer the optimization process.
6.4.2
Manual
Clicking on the button pareto in the model manager closes the model manager and launches the
Pareto manager. The Pareto manager uses the following information:
• all functional relations used to express the values of category-II variables in terms of the
values of category-I variables as they are present in the list of entries in the NanoAccel
model;
• for all category-I variables, the domains as they are set up in various named selection controllers;
• for all category-II variables, the role that they should play in Pareto optimization (whether
they should be maximized or minimized, et cetera; and whether they should be plotted
horizontally or vertically in the Pareto plot). The latter information can be acquired interactively, using interactive dialogues that are initiated by the operation of the Pareto-tool;
alternatively, we can prevent such dialogues by adding clauses such as ’[MAX HOR]’, or
’[IGN NONE]’, et cetera, to the comment fields of entries associated to category-II variables.
When the Pareto manager has produced a Pareto front, solutions on this front can be substituted
back into the model, for instance to serve further manual optimization. After the Pareto manager
has been closed (clicking on the cross in the upper right corner closes the Pareto manager), the
model manager is re-opened, and the session resumes from there.
While the Pareto manager is active, operations center around the following activities:
• starting a new evolution process with a fresh population of solution candidates (by clicking
the reset button);
• proceeding with a next number of generations in the evolution process with the present
population of solution candidates (by clicking the iterate button);
• adjusting the parameters of the present population with the sliders population size, max
nr. on front, or relative accuracy; or
• adjusting the parameters of the evolution process, that is: setting the relative probabilities
of the various mutation mechanisms.
Figure 6.5 depicts a screen shot of the form to control the Pareto process. Apart from the control
form, the Pareto-tool consists of a graphical diagram, called the Pareto box. This allows to visually
follow the convergence process. This Pareto box consists of a square region plus a legenda box.
The square region is colored with a color gradient that develops from bluish-green in one corner to
orange in the opposite corner. The horizontal and vertical directions in the square correspond to
the two category-II variables that were labeled HORIZONTAL and VERTICAL in the category-II
wizard. The bluish corner designates the direction of ’better’ solutions. So the Pareto front should
move in the bluish direction. The current population is depicted as a cloud of points. Every point
has coordinates that are the two category-II variables chosen for plotting. If a point is on the
Pareto front, it is rendered as a slightly larger green circular disk. We can follow the iterative
process of subsequent generations. The motion of the Pareto front (the green circular disks) is a
130
Figure 6.5: A screen shot of the NanoAccel genetic Pareto optimization tool.
131
reasonable indication of the progress of the iterative process. If little or no improvement can be
seen in the Pareto front, the process is likely close to convergence (or: with the current setting of
mutation parameters, it is unlikely that much more progress can be obtained.) Notice that the
legenda box of the Pareto box contain the names of the two category-II variable that are plotted
horizontally and vertically; furthermore, the number of the generation is indicated.
6.4.3
Controls
reset
Starts a new population with magnitude equal to the currently set size of the population, consisting
of all randomly defined individuals.
iterate
Performs a number of iterations with the present population equal to the currently set number of
iterations.
post tune
The Pareto genetic optimization process constructs a number of solutions that are on the Pareto
front. The condition for an individual solution to be on the Pareto front only means that the
solution is not dominated by any other solution. There is no guarantee as to the absolute quality
of the solution. There is a simple additional process, however, called post-tuning, that can take
place after completion of the genetic algorithm, which has a high probability to increase the quality
(in the sense of category-II variables) of the solutions. Indeed, suppose that we have a number of
solutions on the Pareto front. Consider one of these solutions. It corresponds to a combination
of category-I values and the resulting category-II values. Call this solution S. Now suppose that
we could modify a single category-I variable, such that a new solution S ′ arises which dominates
S. Then we should definitely include S ′ in the Pareto front rather than S. It is very simple,
however, to check if tuning an individual category-I variable could yield an improvement in the
sense of domination. Indeed, for category-I variables which are ordinal, we can try to do a small
increase and a small decrease, and check both candidate solutions if they dominate S. If one
of them does, we replace S by the improved one. Next we repeat this with a double step size,
and we continue this process of repeatedly doubling the step size until deterioration in stead of
improvement occurs. Then we go back one iteration, and we have found a solution which clearly
improves on the original S. We apply this to each of the category-I variables. If an improvement
could be obtained with at least one of them, we repeat the entire process, until no category-I
variable could be modified to yield further improvement in the sense of domination. This means
that at the end of the process, the solutions are guaranteed to be local optima. There still can be
many of them, in case the problem had multiple category-II variables.
As a result of post-tuning, the improved solutions are all local optima. But in the process of
improving a single solution, we don’t take dominance over the other solutions into account. So
it is possible that solutions result that should no longer be on the Pareto front. Indeed, by
construction we have ensured that an (improved) solution dominate its original version, but we
do not know if it is not dominated by any of the other (improved) solutions.
However, if we use the newly obtained collection of solutions as the start of a further round of
genetic optimization, and we do not apply the one-by-one post tuning, we are certain that a true
Pareto front results, where the solutions have a very large change that they cannot be improved
by small modification of any of the category-I variables - which is a clearly better position than
we could obtain without post tuning.
In the Pareto tool, post tuning normally should take place only after clicking the iterate button.
First, a number of regular generations of genetic optimization is performed; next, all solutions are
individually tuned to obtain locally optimal solutions. In the legenda of the Pareto box we can see
132
if the process is in te stage of generating generations, or whether it is tuning individual solutions.
Post tuning is evoked by clicking on the post tune button. Even though post tuning only involves
the solutions on the Pareto front, it can be a time consuming process. In particular, post tuning
should only be done if
• the number of individuals on the Pareto front is not too large;
• if reasonable convergence with the regular iterations has been reached.
Even then, if the post tuning turns out to be unacceptably slow, it can be safely interrupted by
clicking the red button ’stop tuning’ that will appear when the post tuning process has commenced.
zoom in
Clicking the button zoom in doubles the scale factor in the Pareto box. This gives a better view
on the detailed shape of the Pareto front.
zoom out
Clicking the button zoom out halves the scale factor in the Pareto box. This remedies the situation where solutions may have migrated to locations outside the box. Neither clicking larger nor
smaller affects the values of any of the model variables; they merely effect the visual representation
of the category-II space.
population size = ...
The slider population size determines the number of individuals in one generation.
nr generations = ...
The slider nr generations determines the number of generations that is evolved at one click of
the button iterate.
max nr. on front= ...
According to its definition, the Pareto front consists of all those individuals in a population
that are non-dominated. In most cases, the number of solutions on the front is relatively small
compared to the total number of solutions. Only when the number of category-II variables is
large, or when category-I variables can assume very many different values (for instance, when they
are real numbers), the chance for a solution to be on the front is relatively large. The fraction
of solutions that are on the Pareto front at each generation is given in the first line of text in
the listbox in the lower left part of the Pareto manager. If this fraction is large (close to 100%),
there are few non-front individuals. According to the standard Pareto genetic algorithm, however,
only solutions that are not on the Pareto front are replaced by new, or mutated individuals. So
if (almost) the entire population is at the Pareto front, there is little or no opportunity to make
further progress. Sophisticated implementations of the Pareto genetic algorithm implement forms
of niching or clustering to the Pareto front. That is, a sufficiently representative subset of the
front is maintained, and the other individuals on the front are ’recycled’. This ensures a sufficient
percentage of mutating individuals, which is necessary to sample a sufficiently large portion of
the solution space. The implementation of the Pareto genetic algorithm in NanoAccel is, in
this respect, rather primitive. With the slider max nr. on front we set a maximum to the
amount of individuals on the front. In case the number of individuals on the front exceeds this
maximum, random individuals are selected for recycling. This has an advantage that the pool
of mutating individuals has at least a given, minimal size - which ensures sufficient chance for
mutations, and hence the possibility of progress. The disadvantage is, that an individual from
the front that was very ’good’ could become degraded. That is, an individual that occupied a
prominent frontal position could nevertheless loose its favorable status as being a survivor for this
generation. In such a case, the progress of the evolution process is not monotonic: a temporary
regression may occur. We don’t want this to happen unnecessarily; therefore the slider max nr.
133
on front initially should be set to a high value. Only if the reported percentage of solutions on
the front becomes dangerously high (say, 70% or higher), it is recommended to move the slider to
a lower value.
rel. accuracy= ...%
For category-I variables that are integers (corresponding to selection controllers with flags ’I’ or
’S’ with integer lower and upper bounds and an integer step size), or enumeration type (’E’), a
mutation always produces an individual which is discretely different from the original one. For
real-valued category-I variables, however, the difference as a result of mutation can be arbitrarily
small. This is fine, since it allows fine tuning for real-valued category-I variables, but it can also
tremendously slow down convergence. Therefore we should have a handle on the allowed step size
in real-valued category-I variables. The slider relative accuracy does this. It can take any of
the values 100%, 10%, 1%, 0.1%, down to 0.000001%. These are percentages of the interval size.
For instance, suppose that a category-I variable has a domain between 0.0 and 50.0, and the slider
rel. accuracy is set to 1%, then a mutation will cause a random change of this variable of -0.5 or
+0.5 per generation. In practice, a good strategy to establish ’optimal’ values for real category-I
variables is therefore the following. First, do a number of iterations with a relatively large value
of the slider rel. accuracy. If no further progress is obtained, reduce the accuracy interval by
a factor 10 (e.g., from 10% to 1%), and check if this gives considerable improvement by another
click on iterate, and so on until the relative accuracy has reached a sufficiently small value.
listbox
The large, grey listbox in the lower area of the Pareto tool first gives the statistics about the
current solution. In particular:
• the number of solutions on the Pareto front;
• the population size;
• the percentage, that is the fraction of individuals in the entire population that are on the
Pareto front.
Underneath, it contains one selectable entry for every solution on the Pareto front. These are
named ’solution1’, ’solution2’, and so on. Clicking on one of these names highlights the corresponding point of the Pareto front in the Pareto Graph. In figure 6.5, the solution ’solution2’ is
selected, and the corresponding point is shown in white. Double clicking a solution pops up a text
box with detailed information on that solution, giving
• a line with the solution number (two strings of asterisks and the string ’Solution X’, where
X enumerates the solutions);
• for each of the category-I variables the value for this solution;
• for each of the category-II variables, preceded by an arrow, the value for this solution.
When the detailed information of a selected solution is listed, the values of category-I variables
for that particular solution are copied into the model. That means: the entries containing the
Sel()-functions with their defaults are adjusted, and the new values of the category-I variables as
taken as new defaults.
The contents of the listbox are updated every time the reset or iterate button are clicked. At
the same time, a file with the name ’paretoFront.amf’ is produced. This file contains as items the
solutions of the Pareto front. In paretoFront.amf, the classifiers are the category-I variables, the
ranking attributes are the category-II variables. In ASSIST the Pareto front can be examined
further, for instance to do a justified choice for a particular solution from the Pareto front.
134
random new
Five yellow-colored sliders control the details of the process of generating new individuals, that is:
new candidate solutions. They all have the interpretation of a probability that a particular process
will happen. Since for every individual that is not on the Pareto front, a new individual will be
constructed, the probabilities for the five separate processes sum up to 1. Therefore, the sliders
only serve to indicate relative probabilities. If we adjust the sliders to a certain configuration,
say, moving random new and cross over all the way to the right and all he others all the way
to the left, the interpretation is that the two processes ’generate a random new individual’ and
’apply crossing over’ are the only two processes that will be used, and they have equal probability.
Therefore, their probabilities will be 50% each, and after the first click on iterate, both sliders
will move to the 50% position.
Now we will describe, for each of the processes, how they work and when they should be applied.
The random new process creates a new individual ’from scratch’. That is, the values for all
category-I variables are selected randomly from the respective domains. This process is best for
creating a broad coverage of the solution space. It has no memory, that is, it does not take earlier
solutions into account.
random mutant
The random mutant process takes an individual from the Pareto front, clones it, and applies,
with a probability set by the slider mutation chance, a mutation to each of its category-I
variables. So if mutation chance is set to maximum (=100%), the effect of random mutant
is the same as random new. A mutation means that the the value of a category-I variable is
replaced by a random new value taken from the domain of that category-I variable. If the slider
mutation chance is set to 0, the process to create random mutants has no effect at all. Random
mutants, as opposed to random new individuals, have some memory. If we mutate only some of
the category-I variables of an individual, it stays, in category-I sense, close to the original, and
therefore it has a chance that it also stays more or less ’close’ in category-II sense (depending on
how ’wild’ the model is). So since the original individual was on or near to the Pareto front, the
new individual has a chance also to be not too far off, and perhaps even in front of the Pareto
front - which means that it will have pushed the Pareto front forward in the next generation.
incremental mutant
The process to create an incremental mutant is similar to the process of creating a random mutant
- except that the new value of a category-I variable is not randomly selected from the domain of
that variable. Rather, a small increment is applied to the old value. For integers this increment is
+1 or -1; for category-I variables with sort ’S’ it is plus or minus the step size, and for real-valued
category-I variable it is an increment that is plus or minus the value as set by the slider rel.
accuracy= ... times the width of the domain-interval. For ’E’-type variables, the increment
means that one of the two adjacent values is chosen; whether or not this is a ’small’ increment
of course depends on the values in the list. If these values are not numeric values, he meaning of
’small’ completely looses its meaning. Notice that the process ’incremental mutant’ has a memory
effect built in, for two reasons: it departs from an individual that was on the Pareto front (and
therefore was a successful individual); further, the value applied to the mutating variable is close
to te original value - which was also successful. So the chance that the mutated, new individual is
close to the Pareto front (but perhaps in front of the front) is even larger than with the ’random
mutant’ process. Therefore, the process ’incremental mutant’ should be prominent towards the
end of the evolution process, once the solutions are almost converged, to obtain a final small
adjustment.
cross over
The process ’random new’ has no memory effect; it takes no earlier (successful) individuals as
starting point. The processes ’random mutant’ and ’incremental mutant’ each depart from a
6.5. VISUALIZATION: THE GRAPH-TOOL
135
single successful individual. The process ’cross over’ departs from two successful individuals. It
resembles sexual procreation, where the genetic material of two (fit) individuals is mixed. Since
both parents were fit (at least to some extend, otherwise they wouldn’t have made it to the
present generation), both their genotypes7 are (to some extend) fit. If we believe that mixing
fragments of two fit genotypes has a large chance to produce a fit genotype - that can nevertheless
be very different from each of the parents’ genotypes, sexual procreation is a good way to obtain
fast evolutionary progress. Evolution biologists believe that this is the reason why, after sexual
procreation had been ’invented’, it more or less has overtaken a-sexual procreation in higher
species. In the Pareto genetic algorithm, the process of cross over works as follows. Two random
individuals on the Pareto front are selected. These will be called the parent individuals. Next, a
new individual is constructed where for every category-I variable, either a value from one or from
the other parent is chosen. Which of the two parents contributes a value is selected randomly for
each of the category-I variables. Since cross over can produce individuals that are largely different
from both of their parents, it is a good way to stimulate broad coverage of the solution space. It
only works, however, if
• there is a sufficient number of category-I variables;
• the Pareto front is sufficiently diverse, that is: there is a sufficiently large number of individuals on the Pareto front, and they are sufficiently different in category-I sense.
This means that in the first few generations of the evolutionary process, not very much effect of
the cross over process can be expected.
binary tournament
Evolution is the process of survival of the fittest. We are interested in the solutions on the Pareto
front, and the ones that are not on the Pareto front are sacrificed: they are replaced by individuals
that are, hopefully, fitter. Nevertheless, it is dangerous to destroy all non-fit individuals too soon.
If we keep a small number of known non-fit individuals alive, these might open up a profitable niche
at some later point in the evolution process. This mechanism inspires to the ’binary tournament’
process. In binary tournament, we pick two non-fit individuals, and allow the fitter of the two
to take part in the next generation. If we would insert it unaltered in the next generation, it
would guaranteed not be on the Pareto front, and therefore it would die out one generation later.
Therefore we modify it by one of the processes described above.
mutation chance
The slider mutation chance sets, for a category-I variable, the chance that it will take another
value in one of the mutation processes ’random mutant’ or ’incremental mutant’.
6.5
6.5.1
Visualization: the graph-tool
A model is rarely built from scratch without any mistakes underway. Like all forms of programming, a model-under-construction might require debugging. Also, it might be very instructive to
get a better understanding of the behavior of (parts of) the model, even if we don’t suspect that
anything might be wrong. To help the understanding of a model, and in particular the various
7 The word ’genotype’ is taken from evolution biology. It refers to the genetic make up of an individual; the
phenotype is the apparent form the individual takes. The phenotype determines its fitness; the genotype is the
information that is inherited from generation to generation. In our context, the genotype is the collection of values
of category-I variables of an individual solution. The phenotype is the collection of values of category-II variables
for the same individual as they are determined by the genotype. As in the biological case, the individual’s fitness
is determined by its phenotype.
136
Figure 6.6: A screen shot of the NanoAccel graph-tool.
dependencies that it consists of, we support graphical visualization of (arbitrary) dependencies.
We can produce a graph for every arbitrary variable as a function of every other arbitrary variable
(provided that the argument variable is a numerical type). This is done by using the graph-tool.
6.5.2
Manual
The graph tool consists of an interaction form where the two variables can be determined (the
argument variable and the result variable); further, we can set a range for the domain, and next
we can command the required graph. Figure 6.6 contains a screen shot of the graph-tool.
6.5.3
Controls
argument
The argument variable is selected from the list box containing all variables. Variable names
between parentheses can not be selected ,as they are not numerical types.
result
The result variable is selected from a second list box containing all the variables. The selection
for an argument and a result variable are free; that is: it is not required that there is a functional
dependency from the result on the argument. If such a dependency doesn’t exist, however, the
graph will be merely a horizontal straight line. In particular, the following mistake should not be
made: suppose that y = x2 . If we plot y as result and x as argument we get the familiar parabolic
6.5. VISUALIZATION: THE GRAPH-TOOL
137
curve. If we swap the roles of x and y, however, we don’t get the curve of the inverse function.
Indeed, the function is not inverted: it just so happens that x is not a function of y. Therefore a
curve will be plotted that, for every y gives the default value of x.
from
The text box from should contain the numerical value that is the lower bound of the argument
variable. This value has nothing to do with an eventual lower bound for a selection controller in
case the argument variable would be a category-I variable.
to
The text box to should contain the upper bound of the argument variable.
draw
Clicking the draw button produces the actual graph.
138
Index
139
Index
DM
-control widget in Questionnaire form, 52
algebraic elimination
to deal with constraints, 84
DP
allow quick ranking
-see problem domain 12
widget in the Preferences tool, 62
.amf
Assist model file: the proprietary file for- analytic
- process to think of the variables that a
mat for Assist projects, 23
given variable depends on, 97
.bu amf
-attitude of Minerva-type professionals, 7
-file extension for Assist backup file; see
-skill in model making, 13
data recovery 23
arc
Assist
directed to represent a dependecy in a model
-acronym for ’Assist Supports Systematic
graph, 97
Innovation by means of Software Toolarchetypes
ing’, 19
-Minerva and the Centaur as -, 7
-how to get started, 20
-intended for option generation, adminis- arrow
to represent a dependency in a model graph,
tration and evaluation, 19
97
-used in option generation and selection phases
assumptions
of decision making process, 15
-as ingredients of a model, 67
absence of cycles
irrelevant only in the case of abstractions,
property of partial orderings, 38
94
abstract
role of in model making, 68
-of an item: the condition that the item has
thinking about as a result from systematic
more than one value for at least one of
developing a model with category-I · · ·
its classifiers, 34
category-IV variables, 94
academic education
underlying mathematical formulas, 94
-related to the distinction synthetic-analytic, atomic
7
simple, opposite to compound; see comaccuracy
pound 81
-see precision 46
attribute
actual column
function from the domain of concepts to the
-the currently active column in the Data
range of values; chunk of information
Grid, 22
of a concept that need to be known
actual row
when making a model, 81
-the currently active row in the Data Grid, attribute score
22
-definition, 47
add item
attributes
-control widget in Query form, 55
-short for ’ranking attributes’, 48
Add new item
auto-ranking
-control widget in Inspire form, 37
a heuristic to estimate a value for a rankaggregation
ing attribute based on the distance becalculation of total item scores from the intween items, measured in terms of the
dividual ranking attribute values, 33
classifier values, 36
agree
auxiliary variables
-see model domain 12
140
INDEX
variables from category-IV, 79
back-up
-recover from crash by means of ’recover option’ in File IO form, 25
bad
criterion for formulating a query, 54
balancing
-checking balancing of classifiers by means
of correlations, 30
-property of good classifiers, 27
binary classifier
-a classifier with two values, 55
Boolean
-of a classifier if the classifier can have the
two values ’true’and ’false’ only, 27
Botticelli
- Sandro, (1445?-1510), Italian renaissance
painter, 7
bottom up
-see propagation 44
bounded
range of values for non-numerical, ordinal
values, 96
button
-an interactive control widget in a form used
to invoke a process, 23
categories
- of variables, 73
distinction between the four categories of
variables, 80
category-I
decision variables, 73
category-II
finding category-II variables starting from
category-I variables, 76
happiness variables, 73
multiple variables, 87
category-III
contextual variables, 79
category-IV
auxiliary variables, 79
Centaur attitude, 7
centroid
-of intervals, 47
of an interval: the average of lower and upper bound, 48
chaotic approach
-as attribute of Centaur attitude, 9
check box
to set or unset a binary (’yes-no’) value,
23
141
child
-intentional, 41
class
-being represented by an item if at least one
classifier has multiple values, 28
classifier
-a function that assigns one or more of a
set of values to an item; e.g. ’color’
assigns ’red’ to ’a tomato’ and ’green’
to ’a cucumber’, and ’red,green’ to ’a
pepper’, 26
classifiers
-definition of, 19
-rationale for constructing an ontology based
on classifiers, 27
-to represent the world knowledge that distinguishes a set of items, 27
classify
-using the information of classifiers and classifier values, 28
cluster, 55
-on the basis of classifier values, 30
Cluster form
-introduction, 55
color coding items: intervals
widget in Preferences Tool, 65
color coding items: Pareto
widget in Preferences Tool, 65
coloring
-colors of items after lexicographical sorting
to verify if items are distinct, 30
-to indicate relative quality of items based
on total scores, 48
column based
-interrogation of data base table, 54
column headers
-the cells in the top row of Assist’s Data
Grid, 22
Combination
comparative relationship
a relationship that involves comparison, 44
comparing
-items on the basis of total scores, 48
comparison
- of values of various category-II variables
in a graph, 95
the partial ordering relationship that formalizes the ’is inferior to’-relationship
between items, 38
compound
of an attribute, that its value is a concept
in its own right, 81
concept
142
INDEX
relevant notion in modeling discourse, 81
-see recover 25
concept generation
creativity
-as part of decision making process, 14
-killed by formalization, 11
conclusions
crossing over
-intervals protecting against unsubstantiated
a technique in the context of evolutionary
- , 48
design, 89
concrete
current project
-of an item: an item that has, for each clas-information about the current project found
sifier, exactly one classifier value. Noin the ’current status’ widget in the
tice: the qualification ’concrete’ is at
File IO form, 26
best a provisional qualification. Any current status
’concrete’ item can become abstract with
-control widget in File IO form, 26
the addition of a new classifier with curriculum
multiple values for that item., 35
-Centaur-type -, 9
conjunct
-Minerva-type -, 9
-logical AND as combination of several ele- cycle
mentary query expressions, 55
as source of confusion in design discourse,
consequence
83
-of a design decision, 67
cyclic
consistency
- dependency, 82
internal and external with respect to moddata recovery
els, 72
-mechanism to avoid data loss in case of
constant
exceptional termination of Assistsee
- as a particular type of variable, 72
recover 23
constraints, 83
database
algebraic elimination, 84
-table of items interpreted as database, 54
dealing with -, 84
decision making process, 14
iteration, 84
decision variables
penalty functions, 84
variables from category-I, 73
context-sensitive
-property of controls to be only enabled when decisions
-design as ’taking decisions for the future
meaningful; disabled controls are invisbenefit of stake holders’, 11
ible see controls 23
-taking - as a definition of designing, 67
contextual variables
default
variables from category-III, 79
- solution is the first solution which comes
controls
to mind, 76
-user interface widgets in a form, 23
delete
conventions
-control widget in File IO form - only in the
for systematic model development, 94
web-based version, 26
convert
-intentional and extensional is-a relations, delete all
-control widget in Relations-form, 40
43
dependency
coordinates
- between category-II and category-I vari-a structure for a collection of ideas, 26
ables, 74
correlate attributes
cyclic -, 82
-control widget in Sort and Cluster form,
represented by a directed edge, a directed
33
arc, or an arrow in am odel graph, 97
correlate classifiers
-control widget in Sort and Cluster form, design
-as a context for discussing synthetic and
30
analytic skills, 12
correlations
-definition, 11
-calculation of correlation coefficients for clasdesigner
sifiers, 32
crash
-as stakeholder, 11
INDEX
143
detailing
-of query expressions, 54
empty regions
difference scale
-areas in a solution space that were not yet
explored, 26
quantitative scale where differences between
scale values have a meaning, 45
empty set
direct manipulation
-interpretation of - of values for a classifier,
28
-see Interactive Weights form 33
enabled
directed graph
-state of a control widget where it can supcollection of points and arrows between them,
port interaction see disabled 23
38
estimating
disabled
- if terms in a model are significant or in-state of a control widget where it doesn’t
significant, 98
allow interaction; disabled control widget is invisible see enabled 23
evaluation
- of a model, 97
disagree
evolution
as a technique to estimate the Pareto front,
disjunct
89
-logical OR as combination of several eleexample
mentary query expressions, 55
of modeling, 93
distance
existing file
-between items, 55
-open an existing file by means of ’open’
distinction
button in File IO form see open file 25
-of classes in the case of extensional is-a reexpectation value
lations, 43
-as expressed by centroid of an interval, 47
distinguish
extensional
-items by means of classifiers, 28
-is-a relations; relation with intentional is-a
domain
relations, 43
- of a function, 73
extensional is-a relation, 41
dominate
if an item A performs better in all ranking attributes than B, we say that A File IO form
-introduction, 24
dominates B, 35
one solution dominates another solution in files
-way to store information for later usage the Pareto plot if it is better in all renot being supported in online Web apspects, 87
plications, 24
dominated
of two items: item A dominates item B if finitely enumerated
-of a set of values for a classifier if the valA is better in all rspects, 47
ues can be spelled out exhaustively in
don’t apply
a list, 27
-of a classifier: represented by an empty set
fitness
of values, 28
see evolutionary design 89
dot-notation
Flash-cookie
see notation 82
- a facility to store persistent data on a local
machine without security risk, 24
edge
directed - to represent a dependency in a Folk-ontology form
model graph, 97
-introduction, 58
forgotton values
educated guesses
risk of using default substitutions for nonto obtain relations between variables, 85
defined values in spreadsheets, 97
to obtain values for variables, 85
form
education
- of dependencies, 96
-of Minerva-type skills and Centaur-type skills,
formal
9
elementary
144
forms
-Cluster, 55
-File IO, 24
-Folk-ontology, 58
-Inspire, 34
-Interactive Weights, 33
-Pareto, 58
-Preferences, 62
-Queries, 54
-Questionnaire, 52
-Sliders, 49
-Sort and Cluster, 26
-implementing the tools in Assist, 20
formula
-in DM being a counterpart for a relation
between things in MP , 12
fresh
of a variable: one that is introduced when
expanding an existing category-II or
category-IV variable, 97
front
Pareto - :collection of non-dominated solutions, 87
full
of ordering: an ordering relationship that
applies to all pairs of items in a set, 44
function
- as a particular type of relation, 73
domain of a -, 73
happiness expressed as a - of design variables, 73
INDEX
hue
property of colors that serves to represent
the comparison-relation, 46
hybrid
-objects cause in-intuitive hierarchical relations, 43
I
category of variables: decision variables,
73
idea generation
ignoring
default boundaries for category-I variables
as source of inspiration for innovative
solutions, 77
II
category of variables: happiness variables,
73
III
category of variables: contextual variables,
79
importance
-of a ranking attribute, expressed by weight,
47
improvement
the version of an item that is better in terms
of at least one ranking attribute - although it may be worse in terms of
other ranking attributes, 35
inclusion
the partial ordering relationship that formalizes the ’is-a’ relationship between
genetic
items, 38
incommensurable
given formulas
-assumed of analytic and synthetic skills, 7
models consisting from - only, 93
independent
good
-of two classifiers if the values of cone clascriterion for formulating a query, 54
sifier don’t predict the values of the
Hamming distance
other classifier when applied to a set
a distance metric based on the number of
of items, 26
classifiers that are different for two items,
35
inferior
happiness
for two connected item-icons, the inferior
as a function of design variables, 73
item is the left one; this is at the tailhappiness variables
side of the arrow. The arrow connects
variables from category-II, 73
to the head of the inferior item, 39
hierarch
inheritance
-in relation to ontology, 41
-relation to ’specialization’, 41
hierarchical propagation of classifier values
inheritance, multiple
-inheritance where a child can have multiple
parents, 41
hierarchy
embodies the is-a relationship between items, initiating a new project
20
-see new 25
INDEX
insignificant
see significant 98
inspiration
for innovative solutions by ignoring default
boundaries for category-I variables, 77
Inspire form
-introduction, 34
instantiate
an abstract item A can be instantiated by
a less abstract item B (for instance: a
’tool’ is instantiated by a ’hammer’) if
the values for any classifier in B are a
subset of the values for that classifier
in A, 34
intention
-as ingredient of a model, 67
-of a model, 12
true of a stake holder, 76
different s require different models, 68
intentional
-is-a relations; relation with extensional is-a
relations, 43
intentional is-a relation, 41
Interactive Weights form
-introduction, 33
intervals
-to avoid pseudo precision, 46
introduction
of a new variable: logical point to think
of variations in the mode of operation
related to what this variable depends
on, 97
intuition
-hallmark of creative professionals, 11
-reconciled with creativity, 11
inuition
for a functional relation between numerical
quantities, 93
Invention
invention
the instantiation of an abstract item into
a less abstract item that did not exist
before, 35
is-a relation, 41
-extensional, 41
-intentional, 41
-liberal interpretation, 42
-restricted interpretation, 42
is-a relationship
-determine - in terms of (sets of) classifier
values, 28
item
145
-new - , resulting from selection in Query
form, 55
item-based
item-icon
a dragable graphical widget in the Relationstool that represents an item, 39
itemName
column header for the item name column,
22
itemRank
column header for the item rank column,
22
iteration
IV
category of variables: auxiliary variables,
79
justifiable
-of decisions: distinguishes professional design, 67
Lagrange multiplier
- to deal with constraints in optimization,
84
levels
design decicions taking place at various -,
76
lexicographical sorting
-to put items in a meaningful order by means
of - on the classifier values, 30
-using the ’sort’ button in the Sort and Clusterform, 30
liberal interpretation
-of is-a relation, 42
limit process
to find category-II variables from category-I
variables, 76
logic
-as attribute of Minerva attitude, 9
logical formula
-expression to single out desired rows in a
data base table, 54
manual
-of Clustering and Visualization form, 57
-of File IO form, 25
-of Folk-ontology, 60
-of Global Settings form, 62
-of Inspire form, 36
-of Interactive Weights form, 33
-of Pareto form, 58
-of Query form, 55
146
-of Questionnaire form, 53
-of Relations form, 38
-of Sliders form for ranking attributes, 50
-of Sliders form for the ’include’-relation, 51
-of Sort and Cluster form, 30
material
-model see model 12
mathematical
-of a model, 12
mathematical object
mechanisms
variables get their values by means of mechanisms, 98
metric
the notion of distance between items, 35
Minerva and Centaur
-bridging the gap between attitudes, 9
Minerva and the Centaur
-painting by Botticelli, 7
Minerva attitude, 7
model
-needed to predict consequences of design
decisions, 67
-skills needed for - making, 13
-the notion of a, 67
behave according to our intuition, 94
evaluation of -, 97
functional - as expressed in spreadsheet, 94
ready: when no more pending category-IV
variables exist, 94
right order of magnitude of outcomes, 94
model domain
-mapped to problem domain, 12
modeling, 12
models
- as consisting of variables, 72
consistency, 72
precision of -, 72
purposes of -, 71
requirements on -, 72
monotonic behavior
ramp function: functional dependency to
model - with saturation, 85
monotonously
- increasing as behaviour of dependecy, 96
multiple category-II variables, 87
multiple inheritance
-see inheritance 41
multiple values
-interpretation of - for a classifier, 28
mutual information
-the principle for choosing propositions in
the automated questionnaire, 53
INDEX
NANO ACCEL
-used in detailing phase of decision process,
15
new
new combination
-forming new combinations of classifier values to inspire new items, 28
new item
-resulting from selection in Query form, 55
next question
no opinion
node
a variable in the graph of a model, 97
nominal
of a scale: a scale that is not ordinal, 45
of variables when they do not allow ordering, 80
non-material
-model see model 12
normalization
arbitrariness w.r.t. - , 86
issue in choosing units and working with
dimensionless quantities, 96
notation
of concepts, attributes, and values, 82
number iterations
widgt in the Preferences tool, 64
ontology
-a structure on the space of possible items,
26
-build the ontology by means of classifyform, 28
-in relation to hierarchy, 41
open
operational
-the property of a classifier that it can be
applied to items with a unique outcome in terms of classifier value(s), 26
operator
-to form elementary query expression, 54
option generation
order
- of expanding variables to develop a model,
97
ordinal
of a scale: a range of values that are the
outcome of an assessment that allow
(partial) ordering, 44
INDEX
147
of variables when they allow ordering, 80
-of detailing, 15
orthogonal
-of selection, 15
-of classifiers: the property that classifiers propagating adjustments
apply to all items of a set and give inas a consequence of adjusting the values of
dependent information, 26
ranking attributes by means of sliders,
50
orthogonality
propagation
-checking orthogonality of classifiers by means
-of is-a relations through graphs, 43
of correlations, 30
pseudo precision
-intervals to avoid -, 46
parent
pseudo-accuracy
-intentional, 41
see precision 72
Pareto
purpose of sorting
- front-ranking, 47
-items with respect to classifier values, 30
-visualization, 58
purposes
disadvantages, 88
- of models, 71
evolution as a technique to estimate the
Pareto front, 89
qualitative
local improvements, 90
-aspects of decision making process, 15
post processing, 90
quantify
Pareto form
how to non-numerical variables, 96
-introduction, 58
quantitative
Pareto front
-aspects of decision making process, 15
see front 87
Queries form
the collection of all non-dominated items,
-introduction, 54
48
query, 54
Pareto plots
query-based
- for dealing with multiple category-II vari-interrogation of data base table, 54
ables, 87
Questionnaire form
partial
-introduction, 52
of ordering: an ordering that applies only quick ranking
to selected pairs in a set, 44
an interactive widget to adjust a ranking
partial ordering
attribute value, 62
the underlying formal notion of both the
ontology and the ranking system in As- ramp
functional dependency to model monotonic
sist, 38
behavior with saturation, 85
penalty functions
random mutations
plotting
design, 89
- several category-II variables in one graph,
ranking
95
-manually setting weights, 33
population
ranking attributes
-definition of, 19
precision
-used for administrating scores of items, 48
- of models, 72
-avoiding pseudo-precision by means of in- ranking process, 48
ranks as colored boxes
tervals, 46
-the pathway of the professional, 9
ratio
Preferences form
-introduction, 62
problem domain
ratio scale
-mapped to model domain, 12
quantitative scale where ratios between scale
values have a meaning, 45
process
-of decision making, 14
re-sort after summation
148
widget in Preferences tool, 64
ready
of a model: when no more pending categoryIV variables exist, 94
reality
-as far as concerned in design contexts, 67
record
-row in a database table, 54
recover
-mechanism to mitigate effects of exceptional
termination of Assist, 23
redundant
-classifiers are redundant if they are not
very orthogonal, 27
from a partial ordering relation: a relation
that can be derived by transitivity from
other relations, 38
relation
function as a particular type of -, 73
relations
between variables, 73
remote database
- storing Assist projects in a remote database, 24
requirements
- on models, 72
reset null
-control widget in Sliders form, 52
reset original
residue
the absolute difference between the total
scores as set by the user and as calculated from the current attribute weights
and the ranking attribute values, 51
restricted interpretation
-of is-a relation, 42
resurrection
design, 89
root-path
a sequence of nodes leading from a single
category-II variable, 97
row-based
INDEX
save as
scale
range of values that may allow some form of
ordering (ordinal scale); if there is no
ordering this is called a nominal scale,
44
score, attribute
-see attribute score 47
score, total
-see total score 47
selecting
-make a selection of items on the basis of
characteristics expressed in terms of classifiers, 30
selection
-those items that satisfy the current list of
elementary query expressions in the Query
form, 55
in the context of evolutionary design, 89
sensitivity
of category-II variables for category-I variables, 86
shared memory
- storing Assist projects in shared memory,
24
sharp
Shepard interpolation
a method to smoothly interpolate values on
the basis of distances, 36
siblings
-nodes that share a parent with a given
node, 44
significant
terms that should be incorporated into a
model, 98
simple
atomic, opposite to compound; see compound 81
single value
-interpretation of - for a classifier, 28
singleton
a class containing a single element, 41
skills for model making
-see model 13
saturation
slider
property of colors that serves to represent
the inclusion-relation, 46
to set a (numerical) value, 23
ramp function: functional dependency to sliders
model monotonic behavior with -, 85
-control widget in Interactive Weights form,
save
34
INDEX
Sliders form
-introduction, 49
smart questionnaire
widget in Preferences tool, 65
solution space
avoid exloring the entire -, 76
broadest if the true intention of the stake
holder is known, 76
sort
-as part of manual optimization, 34
-control widget in the Sort and Cluster-form,
30
Sort and Cluster form
-introduction, 26
specification
of a functional relation, 93
spreadsheet
functional model is often expressed in - , 94
stake holders, 11
starting Assist
-see Assist how to get started, 20
statements
-consistent framework of - as ingredients of
a model, 67
statistical distribution
- rather than single numerical value should
represent outcome of measurements, 94
step
of systematic model development, 95
stepsize
stochastics
dealing with by means of a model expressed
in average values and (simple) assumptions about statistical distributions, 98
structure
-of the lecture notes, 15
structured approach
Substitution
superior
for two connected item-icons, the superior
item is the right one; this is at the
head-side of the arrow. The arrow connects to the tail of the superior item,
39
symmetry
as a requirement of functional behavior, 93
as requirement to functional dependency,
96
synthetic
- process to think of the variables that a
given variable depends on, 97
149
-attitude of Centaur-type professionals, 7
systematic approach
taxi company
as an example case for systematic model
development, 95
tools
-implemented by means of forms, 20
top-down
-see propagation 44
total score
-definition, 47
transitivity
property of partial orderings: from a < b
and b < c, it follows that a < c, 38
tree
shape of the dependency graph for a systematically developed model, 97
try
type
- of a variable, 72
- of an attribute as the collection of values
that this attribute can hold, 81
un-structured approach
uncertainty
-as expressed by width of an interval, 47
unsubstantiated conclusions
-intervals protecting against -, 48
Use weights
vague
value
- as a concept in its own right, 81
- of a variable, 73
contents of a variable; result of applying an
attribute to a concept, 81
variable
- as a container of a value, 72
considerations for introducing a new or to
expand into an expression right away,
99
defined as an attribute applied to a concept,
81
mechanisms by means of which variables
get their values, 98
150
represented by a node in the model graph,
97
type of a -, 72
value of -, 73
variables
- as ingredient of models, 72
auxiliary occupy category IV, 79
categories of -, 73
contextual occupy category III, 79
decision occupy category I, 73
happiness occupy category-II, 73
nominal or ordinal -, 80
relations between - , 73
weighted sum
- - ranking, 47
weightless
-Pareto-front-based ranking, 48
width
-of intervals, 47
Wild substitute
world knowledge
-what we know of a set of items, and what
should be captured in a set of independent, orthogonal, operational classifiers, 27
XML
-a format to store arbitrary data, used to
export and import Assist projects, 24
INDEX

lecture notes - Kees van Overveld`s

Transcription

Similar documents

7 Quality Tools

Understanding and Defending Against Malicious Crowdsourcing

CRImage a package for classifying cells and

Syed Ferhat Anwar, PhD Professor Professor Institute of Business

AccuSizer™ Belt Grader / Classifier Systems

AccuSizer™ Belt Grader / Classifier Systems

Welcome New - Presse Commerce