The parable of the poisoned arrow

There was not much to conclude from our talk this week. However, we did all enjoy this story…

If we are concerned about 'what created the world?' and 'why are we here?' then consider the parable of the poison arrow.

A man went to the Buddha insisting on answers to these questions, but the Buddha instead put a question to him: "If you were shot by a poison arrow, and a doctor was summoned to extract it, what would you do? Would you ask such questions as who shot the arrow, from which tribe did he come, who made the arrow, who made the poison, etc., or would you have the doctor immediately pull out the arrow?"

"Of course," replied the man, "I would have the arrow pulled out as quickly as possible." The Buddha concluded, "That is wise, for the task before us is the solving of life's problems; until the problems are solved, these questions are of secondary importance."

Life does not depend on the knowing how we got here or what will happen after we are gone. Whether we hold these views about these things or not, there is still suffering, sorrow, old age, sickness, and death.

PhD Structure

Themes: informality, interaction

Titles:

Informal aspects of interaction with computer-based artefacts

1. The role of the informal

– What is formality? What is informality?

– Computer science -> making the informal into the formal.

2. Informality in programming

– Psychology of programming

– Groups, teams and projects (the individual vs the group)

– Empirical modelling bridging the gap

3. Informality in languages

– natural vs programming languages

– agent-oriented parser

4. Social interaction (informality in robotics)

– simulations

– robotics

Natural languages and programming languages

A paper by Peter Naur (1975), entitled 'Programming Languages, Natural Languages, and Mathematics', makes some interesting comparisons based on the history of these three fields. Firstly, it points out that the split of mathematics into pure and applied is very similar to the difference in programming between the computer scientists and industry. However, more interesting is the comparison between programming languages and natural languages.

Firstly, natural languages are mostly used in a spoken form, and have evolved through speech, whereas programming is a writing activity. Programming languages are generally formal, and are intended to be interpreted in a well-defined way. In contrast, natural] languages are intended to be understood "only in a fuzzy way, conveying roughly the speaker's subjective reaction to some not very precisely defined circumstance of the world." Naur goes on to say that natural language has greater power because: "A natural language provides an extensible universe of discourse that allows new notations, such as programming languages, to be added at will."

This argument seems to make sense when you look at the area of pragmatics. In 'Meaning in Interaction', Jenny Thomas outlines the ways in which we try to make meaning of interaction in natural language. Many formal theories have been put forward, but none are able to explain the whole range of expressions that we encounter in everyday language.

The power of informality is of great interest. In a scientific world where much emphasis is placed on formal theories, it is easy to neglect the informalities that are taken for granted in life. However, it seems unlikely that we will ever fully understand the informal, as the very act might constitute a formalism!

Another comparison worth considering in Naur's paper is that of literature. This is obviously quite lacking in programming languages, mainly because people generally do not read program code. Perhaps they should; maybe in the future we will have great works by famous programmers that are an inspiration to the rest of the programming masses.

Untangling karma (or kamma)

When this is, that is. From the arising of this comes the arising of that. When this isn't, that isn't. From the stopping of this comes the stopping of that.

There are many misconceptions about kamma (often refered to in sanskrit as karma). Westerners often associate kamma with fate or moral justice, making comments on negative personal situations like, "It must be my bad karma!" However, kamma is not the same as fate — in fact, kamma is about having free-will over your actions. Other people consider kamma to be like money: You can earn kamma by doing good things, you lose it by doing bad things and as long as you don't go over-drawn on your karma bank account you will be fine. This is also a misconception.

The word 'kamma' translates as 'action'. All actions are bound by the law of cause and effect. Each of our actions, no matter how small, have an effect. This law is one which scientists should be quite comfortable with, it is like saying that everything happens for a reason. A well-known physicist is famous for proving: 'For every action there is an equal and opposite reaction'. Over 2000 years prior to this, the Buddha had already pointed out that every action has an effect that is relative to the intention of the act. The effect may be immediate (e.g. you give someone a present and they are happy) or it may not occur immediately but, instead, the fruits of the action may come later (e.g. you teach someone and it becomes useful later). In actual fact, human behaviour is so complex that an action may have effects now and in the future. Who is to know what effect this blog entry might have in the future? — Probably very little! Kamma, then, is not a simple linear sequence of cause and effect but something that could span weeks, months, years, and lifetimes.

At this point we realise that we may never understand even a small proportion of the effects of our actions. If we really were able to see the consequences of our actions then it is likely that we would be much more careful people — people in power, leaders, politicians take note!

The weight of mountains

Writing about web page http://www.accesstoinsight.org/lib/modern/thanissaro/mountains.html

Last night there was a discussion on 'suffering' by the Buddhist Society, this short quote from Thanissaro Bhikkhu sums it up nicely:

Is a mountain heavy? It may be heavy in and of itself, but as long as we don't try to lift it up, it won't be heavy for us. This is a metaphor that one of my teachers, Ajaan Suwat, often used when explaining how to stop suffering from the problems of life. You don't deny their existence — the mountains are heavy — and you don't run away from them. As he would further explain, you deal with problems where you have to and solve them where you can. You simply learn how not to carry them around. That's where the art of the practice lies: in living with real problems without making their reality burden the heart.

Next week the discussion will be on 'karma' — Thursday Week 4, 7pm in S0.09.

Notes on dependency

One of the main principles underlying the model-building activity is `dependency'. A dependency is a relationship [that is always maintained] between one or more things (artefacts, objects, ideas, etc). A common analogy is with mechanical systems, where one component directly affects another component (the dependency). There is no state where one component is out-of-sync with a related component. In a system of mechanical gears, if gear A is connected to gear B, then rotating gear A will cause a relative rotation in gear B. Therefore, the position of gear B is dependent on the position of gear A.

The tkeden environment enables the modeller to describe a dependency relation, which the tool will ensure is maintained at all times. In the previous example, the relationship could be described as:

gear_B_rotation is 2 * gear_A_rotation;

This would model the situation where gear A has twice as many teeth as gear B (a ratio of 2:1). A quarter turn in gear A would result in a half turn in gear B. The dependency maintainer in the tkeden environment provides the indivisible communication of change such that the model is never in a state where gear A has changed and gear B has not been updated. The strong connection will exist until the dependency relationship is broken (i.e. the dependency is removed).

The guarantee of the dependency maintainer allows the modeller to assume that the objects of a relationship will never get into an inconsistent state. As the model develops, the number of dependencies is likely to increase leading to an ever complex state-space. However, the environment is maintaining the consistency of all the related observables and taking this responsibility off the modeller. Hence the modeller is free to concentrate on the actual model-building. If a third gear is added to the mechanical system above, which is also connected to gear A, then one new dependency can be added to the system: gear_C_rotation is 0.5 * gear_A_rotation;. As it is gear A that causes a change in the new gear C, one may assume that it is gear A that requires modification, but there has been no change to gear A. The only change to the system is the addition of a new dependency. Large systems of dependencies can be built up from simple relationships, with the benefit to the modeller that the consistency is always maintained.

Notes on <span class="caps">LSD</span>

The LSD notation is used for describing an agent as if from the

perspective of the agent itself. An agent description is a collection of

observables that may relate to the agent as observables that:

• belong to the agent (refered to as states).


• the agent can respond to (refered to as oracles).


• the agent can change and other agents can respond to (refered to as handles).