Previous Up Next
Dutch / Nederlands

Diary, August 2013

Sun Mon Tue Wed Thu Fri Sat
                  1   2   3
  4   5   6   7   8   9  10
 11  12  13  14  15  16  17
 18  19  20  21  22  23  24
 25  26  27  28  29  30  31

Friday, August 2, 2013


In the afternoon, a LG DVD-writer GP50NB40 was delivered. I bought this because it can write M-discs. In the evening, I tested it by playing the DVD of the movie Smart People with the latest version of VLC on NC10 notebook. That seems to work okay, until the notebook shut-down due to a low battery condition because I had forgotten to plug in the power cord. After this, VLC was behaving odd when I tried to play the DVD, especially when I tried to jump to the place where I had left watching the movie. I ended up playing the movie from the start.

Yesterday, I cleared out a box of old floppy disks (5¼ and 3½ inch). I already had made copies of most. I did not encounter any data errors when comparing the contents with data on hard disk, while some of those floppies are about 20 years old. Found some files from 1988. I also found three .tgz files with the sources of Linux 1.1.59 which were part of the Slackware Linux 2.1.0 distribution from 1994 (download). I only kept six as a memory and threw all others away.

Saturday, August 3, 2013


At 14:07, I bought the following two books from bookshop Polare:

I also saw the book Kleur in Beeld and discovered that pages 140 and 141 have the article: "De Forbo Colour Space" dealing about the Marolleum Colourful Greys that Peter Struycken designed for Forbo Flooring Systems.

Thursday, August 8, 2013

Swapping not the answer

On June 14, I wrote that moving is swapping. But this morning, I realized that there is a better way to implement semantics based locking for moving elements in an ordered collection. If you have an ordered collection of ten elements and one user wants to move element 2 before element 6 and the other user want to move element 8 to before element 4, then the two regions in which the elements are moved overlap, and seeing those moves as swaps would result in a conflict. It is clearly that the two moves can be merged without problem and that there is no conflict. One would need to only lock the affected previous and next relationships between the elements. For the first user that would be the borders before the elements 2, 3, and 6, and for the second user the borders before the elements 8, 9, and 6, where each border is meant to be a pair of previous and next relationships. A conflict occurs when a border needs to be changed by more than one user. But this is not sufficient. When one user moves a range of elements to a different spot and the other user moves a range of elements around this spot inside the range of the first user, all things get mixed up, resulting in elements being removed from the original sequence and put into some (two, I guess) infinite sequeces. This means that an additional check needs to be implemented, which checks if that all changes are applied, no elements are removed from the sequence. When we want to allow users to undo their work, and thus return to an earlier state, it means that we have to check for all combinations of states that the have encountered. This is only needed for parts of the sequence that contain overlapping moves (swaps). This approach also works well together with inserting new elements and deleting existing elements. These operations also introduce locks on the borders, at least for inserts. Maybe it is not needed for deletes.

Sunday, August 11, 2013

Dismanteling ester

In the afternoon, I got the PC ester from the attic. I tried to start it, but it did not come further than the Windows 98 start-up screem. It said something about the configuration being broken and restoring to an older version. But that older version also did not start-up. I took the two drives out and later also the network card. I connected the drives, one after the other, to lixia. The first drive only contained the operating system. When I connected the second drive, it gave some strange symbols in the BIOS set-up, and it was also not recognized. Then I realized that it was configured as a master IDE drive. After I removed a jump to change it into a slave IDE drive, it did show up. I spend some time copying the data on that disk on the new USB drive. I will keep the drives, but will despose of the rest the coming week, together with some more computer parts, like old 5¼ floppy disk drives.

Monday, August 12, 2013

Testing ester

In order to decided which computer parts I can throw away, I tried to start-up annabel, our first PC. I heard the hard disk start, but after that it did not make any other noises as if it were booting into Linux. Also the monitor attached to the video card remained black. I tried playing arround with it, checking all connectors, and moving the video card to a different slot, but it did not result in any improvement. I had some idea to see if I could connect it lixia. At first it did not show up, and when it did the reported disk size was zero. When I tried a similar hard disk, it gave the same result. So, still no conclusive answer to why annabel did not want to boot. I had some idea to connect it to our home network, but I think for the moment I will simply declare it dead. I think, I will still keep it in loose parts.

Sunday, August 18, 2013


Yesterday and today, I attended Zomergo, a rather relaxed Go retreat. I only played three games of Go, two of which were part of the tournament, and one informal game. I won both tournament games against Francien (yesterday) and Wytze (today). Early this morning, Jord invited me for a game, which I lost with a few points. I enjoyed all the games that all were won with a few points difference. The rest of the time, I talked a lot with everyone. The dinner yesterday, prepared by Marieke, was very nice.

Kröller-Müller Museum

This afternoon, I visited the Kröller-Müller Museum. I know that they have some works by Peter Struycken in their collection, and I had hoped to see some, but non where on display. Here a list of works that I have seen and that I liked:

Thursday, August 22, 2013

Ecclesiastes: Annotated & Explained

Finished reading the book Ecclesiastes: Annotated & Explained by Rabbi Rami Shapiro, ISBN:9781594732874, which I started reading on August 16, the day I received it from online bookstore Polare.

In this book Rabbi Rami Shapiro gives a non-religeous, spiritual interpretation of the book Ecclesiastes from the bible. He argues that the Hebrew HaElohim, "The God", is not the anthropomorphic God of the Hebrew Bible, and suggests that should be seen as an impersonal force, which probably is best translated with 'reality'. That the concept is closer to the Chinese understanding of Tao than the classic Jewish, Christian, or Muslim notion of God. He argues that the verses 12:9-14, which oppose this interpretation, where later added to change make it compatible with the other Jewish scriptures. He also argues that the Hebrew hevel is better translated with emptying or impermanence than with vanity. That the message of the book is that we should learn to live with this impermanence and continuous emptying of life and that we should learn to live wisely: eating simply, drinking moderately, working meaningfully, and cultivate love and friendship.

Besides an translation with annotations and citations from other wisdom literature, the book starts, after the forword by Rev. Barbara Cawthorne Crafton, with an introduction and a chapter on the translation. The writer gives an interesting and refreshing interpretation of this age old book, but his attempt to eradicate "the God" from the translation, has sometimes led to a little forced translation, I feel. I also find it remarkable that all statements made by Jesus are taken from the Gospel of Thomas (a non-canonical sayings-gospel with a strong gnostic tone), while many of those also appear in the New Testament. Possibly this has to do with the fact that almost all citations are taken from the other books by the publisher.

Wednesday, August 28, 2013

Flower in magnolia

This morning, I noticed a flower in our magnolia. It was still closed and already had some brown lines on the edges of the leaves possibly caused by the fact that there was a green leave just above it. In the evening it had partially opened, and I took a picture of it. I cannot remember having it seen produce a flower so late in the summer.

Friday, August 30, 2013

Conflict resolution

Last evening, actually very early this day, I thought about conflict resolution for merging two version of an (unordered) object tree. The situation is that you are having an object tree in which some changes are made with respect to some base revision and that you want to integrate ("pull") changes made in another object tree. All objects are identified by a unique identifier (for example an automatic generated GUID). Object can also have forcing references to other objects, in the sense that object they point to need to exist in the given revision of the object tree. Examples of these are relations. All object have a parent to which they belong, but some objects are floating, meaning that they are placed according to some rules with respect to the forcing references. For example, it could be the case that relations are always placed with the closest common ancestor of the object they reference.

The kind of modifications that can be performed on the tree are: adding an object, removing an object, moving an objects, and modifying an attribute of an object. The merging process starts with comparing the current and other revision of the object tree against a selected base revision. The user is free in selecting the base revision, but the selection will have an effect on the number of differences that are found and how these are presented to the user. For example an addition in the current revision could be represented as a removal in the other version, when a different base revision is selected. Because the user is free in selecting the base version, it is possible that both working revisions (the current and the other) contain the same kind of modifications.

During the merging process it is best to start integrating the additions made in the other revision, than proceed with the moves that are made, and from this proceed to the removals, and finally deal with the changes made to the attributes. When processing the additions, one should sort the additions based on the dependencies. An object depends on another object when it has a parent-child relationship or when it does have a forcing dependency. With respect to the objects that are added in the other version, the following situations can occur:

With respect to object that are moved in the other revision, one can accept these moves, as long as an object is not moved to one of its children (and thus creating an infinite loop). If an object is moved to a object that has been removed in the current revision, the move can only be applied when the object is recreated, or possible an alternative parent can be selected.

Also with the removals it is best to process these in the order based on the dependencies. For parent-child relation one should use the dependency in the current revision, while for the forcing dependencies one should follow those in the other revision. (This could possibly lead to problems due to the rise of dependency cycles, but there are some simple and practical restrictions that one can enforce on the object model, that will avoid these.) An object in the current revision can only be removed when it has no child objects or when it does not have a forcing dependency from another object. If it does have children, these children could be moved to another location. It is possible that some of the children (including descendants) are additions from the other revision themselves, which means that an earlier made decision in the conflict resolution has to be changed. When it is decided that the removal should be applied, objects that were added in the current revision and that have a forcing dependency should also be deleted (possibly recursive).

Resolving conflict between the attributes of the objects can be done as a last phase, by showing the conflicting values and allowing the user to select one or create an alternative value. Somehow it sounds doable to apply this method to merging revisions, but because some of the decisions are interdepended, creating a user interface which allows earlier decisions to be revised, might be rather complicated. Also in a 'distributed' context, where revisions are merged between relatively independently branches of revisions, it is possible that the user is presented with the same modification at different merge steps. For example she could have rejected a removal from an object from revision A, but when later this removal was accepted in revision B, and she then performs a merge from revision B, the same object removal is encountered again. In some case it would be nice to remember the previous decision made, but one should also leave the possibility open, because the removal might now make sense. But I am afraid this is but one of the many open issues that still exists.

Saturday, August 31, 2013

Six colours on six by six square

This is the arrangement of six colours on six by six squares that Peter Struycken has selected for his paintings. He selected this arrangement with the help of his son, who wrote the software for making a selection based on specific criteria. He acknowledges that it is not perfect, knowing that an arrangement meeting all possible criteria with only six colours is impossible. I modified my program such that it would print out the scores for the different criteria it checks on. I also extended it with some additional checks, because I discovered that it did not implement one of the criteria they used for their selection. Below an interpretation of the results it produced on this arrangement. Any specific choice for certain criteria over other criterias will result in lower scores for those criteria. It should also noted that some of the criteria, which are easy to test by program are hard for people to spot, and the other way around. These are the criteria Peter Struycken mentioned to me: From the analyses, it is clear some other criteria were also applied.

With respect to symmetries, the program returned that there are at least two colours that have the same placement except for some rotation and/or mirroring. Took me some time to discover that the placement of the magenta squares is the same as the green when these are rotated by 90 degrees to the right. While searching for the combination, I discovered that on each side the second and fifth square have the same colour. There is also at least one colour that when rotated and/or mirrored has four squares at the same position. Again, this took me some searching, but I did discover that the green squares when mirrored around the horizontal axe have four squares at the same location, namely the four squares placed along the sides.

With respect to the one square being embraced by two squares of the same colour, the program returns that there are two of these in a horizontal direction and that these are not overlapping or very close to each other. Actually, they are quite far from each other, and I guess that this might be another selection criteria that was being used. One of embracements is part of a triangle configuration, where the embracing squares have a horse jump with a third square of the same colour. This is the fact for the colour red.

There are a total of 24 horse jumps between squares with the same colour. The number may seem high, but it is only slightly above average. There is one colour that has five horse jumps. This is the colour red. (This is also quite common.) However, there is no combination of four horse jumps that form a tilted square. This rules out the possibility of a 'wheel' pattern, which is made out of two such squares around the same center. The program did not find any square that is part of four or more horse jumps. A total of 31 squares are connected with another through a square jump. This number is rather high, but due to the fact that there are few squares with many jumps.

The program also did find one partial 'wheel' pattern where two of the eight squares have a different colour and three patterns where three squares have a different colour. The 'wheel' pattern with two squares of a different colour is found in the top middle with the colours yellow and green.

The program did not find any pair of colour combination side-by-side (either horizontal or vertical) with the colours in the same direction and did find four such pairs with the colours in the reverse direction. (An example of this are the colour combination magenta and cyan in the last two columns.) This matches exactly with the stated requirements. The program concluded that there are no pair of adjecent rows or columns in which two such pairs occur. I guess that this is another criteria that may have been enforced.

The program did conclude that there is a sequence of four colours that appears more than once. It did not report how much there are of these, but one sequence is the sequence red, green, yellow, cyan, which occurs in the fourth and sixth row from left to right.

The program did conclude that there are no colour combinations that only occur in a vertical direction or in a horizontal direction, which is in accordance with the last stated criteria. It did find that there are two colour combinations that occur three times in the same direction. These are the combinations green with cyan and green with magenta.

It would not surprise me if some of the 'defects' that I mentioned here, where not observed by Peter Struycken and his son. He remarked that once you have noticed a certain defect it will stay in your mind and you cannot keep yourself from seeing it. I hope that my findings do not cause them to change their minds about their choice. It is a kind of maddening problem, because the more you look at it, the more kinds of defects you notice, and the harder it becomes to decide which kinds of defects you find acceptable and which not. Maybe a more quantitative approach where each kind of defect is evaluated against how often it occurs in the whole collection of arrangements, could be of some help.

This months interesting links

Home | July 2013 | September 2013 | Random memories