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.
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.
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.
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.
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.