Tuesday, September 14, 2010

On sending "beer" and receiving "ber"

Let me preface this post by apologising for the fact that I haven't posted for quite some time. Let me try to make it up by posting four articles at once ;)

On Thursday (09-09-2010) we learned about the AB protocol. We did this by acting out a Technodrama again. Two people participated in the Technodrama: one of them was the sender, and the other one acted as the receiver. The sender had to send a message to the receiver, and this could only be done one letter at a time. The problem was that the medium they use to pass their messages is unreliable. This means that once in a while a message doesn't reach its destination. The only guarantee they had was that when you send an infinite number of messages, not all of them will be destroyed.

At the first attempt, the sender would just send all the letters to the receiver. Unfortunately, the unreliable medium made sure that a lot of messages didn't end up at the receiver, but were destroyed instead. To circumvent this problem, the sender just kept on sending the destroyed letters. In real network communication though, it is impossible to see which messages are lost on the way to the receiver, so the result of just sending all the letters to the receiver would be that the receiver might have some letters of the word, all of them, or end up with no letters at all.

At the second attempt, the sender put a number next to each letter she sent out. In this way the receiver would know that either she got all the letters that were send to her or that she missed some letters. When using this method there are two problems: first of all, you can't do something with the information that the receiver has not got all the letters. Moreover, the receiver has no way of telling that the word has ended. In other words, there is no way to tell the communication has ended.

Both these problems were solved in the final attempt. This time the sender would send a letter with a number, then wait for confirmation from the receiver for a certain time, and when this time has ended without confirmation, the sender would send the message again. At the end of the word the sender would send an “end mark”, signifying that the communication has ended.

In the second part of the lesson we discussed languages, mainly the difference between natural languages and formal languages. The most important difference between them is that in a natural language the meaning of the words are not strictly defined (one word can have multiple meanings), while in a formal language a word can have only one meaning. Another significant difference is that a natural language evolves because the community “owns” its definition, while the definition of a formal language is “owned” by one company, and as a result has little to no change in definition (of course new words can be added to formal languages, but the meaning of existing words are seldom changed).

At the end of the lesson we had to design a formal language, in groups of 4 or 5, with the purpose of describing how to draw buildings. All the groups that presented their ideas ended up with a system based on lines, their length and their direction. Our group ended up with a system of shapes, drawn in a size relative to the other shapes.

After four groups had presented their ideas, our teachers made clear that we could have designed a language that doesn't describe how to draw lines, or even shapes, but perhaps common elements in buildings (windows, roofs, doors) or maybe even complete buildings, which makes the language specifically suited to the task it must perform. This made clear to me that we hadn't paid attention to the sheet about designing a “proper” formal language, which contains the following points:
  • understand the purpose
  • understand the domain
  • capture the essential concept
  • identify the basic "compositional mechanisms"
  • understand the users
Lesson learned: read and understand the sheets before you try to "reinvent the wheel".

No comments:

Post a Comment