Friday 28 April 2017

On parts and properties

Looking to refine the build of the ship of the line at reference 3, we have come to think about parts and properties, by way of references 1 and 2.

With particular emphasis on how an object or a part of an object would be different from a property in the two and a half dimensions of our layered data structure.

In reference 2, we have already used the size and shape of the patterns on which our elements are defined to tell us the mode – sight, sound, touch, whatever – of the parts of layer objects – where both ‘part’ and ‘layer object’ were given special meanings in reference 1. Whereas in most of what follows we use both part and object in the ordinary way. So for distinguishing objects, their parts and properties we need something else, something other than the size and shape of those patterns on which their elements are defined.

The first thought is that the difference between a part and a property is perfectly clear. A gun turret is a part of a ship of the line, whereas its class – first rate, second rate, whatever – is a property. Leaving aside the complication that a ship of the line might have a lot of gun turrets and in order to get to a part we need to say which one. With the collection of gun turrets not generally being thought of as a part. While the number of gun turrets is a perfectly good property.

If we think of sets, a part is a proper subset, with a partition being a collection of subsets which do not overlap in any way but which, in total, amount to the set as a whole. So our ship of the line can be thought of, in side elevation, as a large, two dimensional set of small rectangular cells, with seven subsets: its hull, its engines and fuel; its bridge and control systems; and, its guns and ammunition. These seven subsets or parts do not really amount to the whole, but for many purposes they are good enough.

While a property says something about the set as a whole. The number of members, the number of members which are yellow, the average value of the members or the number of recognised subsets – or parts.

Which leads to the notion that the value of a property is something very simple, a choice from some small number of choices available. At the very most, in mathematical jargon, a countable number of choices. Something that one can enumerate or count in the way of the non-negative integers. Or we might go so far as to allow a decimal number, a real number or, in the jargon of Visual Basic, a single. Leaving aside the complication that real numbers do not really exist in computers, with computers being finite never mind countable, only good approximations to them.

Now suppose the object in question is one of our rectangles. At the most basic level, leaving aside Powerpoint complications like line and fill, a rectangle can be completely specified by four numbers, two for its position and two more for its shape. So this object is completely specified by four simple properties. But not many real world objects are this simple, are not readily described in terms of their properties.

The name of a property is this simple, just a word or phrase. While the map which takes one from an object and the name of a property to the value of that property for that object is likely to be complicated. The map that takes us from ‘HMS Vanguard’ and ‘displacement in decimal thousands of long tons’ to the value 44.5. But a complication which we can leave aside, with all that heavy lifting having been done in the course of building our data structure, a building which culminates in what we are calling its compilation.

What about more complex properties? What if one wanted the A turret of our ship of a line to be considered as one of its properties, a property with the name ‘A turret’ – leaving aside the minor complication that numbers and names are also used to label turrets, as well as capital letters. With any particular navy having a convention which gets you from the property name, in this case ‘A turret’, to a turret on a real ship, in this case the one nearest the bows. To all of which we respond with exclusion. Such things are not properties, they are parts.

What about objects which you can’t see, which exist in time but not in space, at least not in the way of a ship of the line? An object like a piece of music, an object which might also be considered to have parts, parts in two dimensions. One dimension being the division of the music into lines, say one for tenor and one for trumpet, the other being the division of the music into time, say bars or movements. Which we allow, with music being distinguished from painting by the mode of its expression, the size and shape of its constituent elements. See reference 2.

From all of which we arrive at the notion that an object is a complicated thing which may be divided into parts, parts which may well be considered as objects in their own right. While properties are simple attributes of objects, attributes which can be specified by a string of the form ‘<object_reference>:<property_name>=<property_value>’, with such strings generally being quite short, say less than a few hundred bytes in computer speak. With something like a picture generally being a few tens of millions of bytes.

Which notion excludes things like smell. So the smell of a rose might ordinarily be thought of as a property of that rose, while at reference 2 we talk of smells being quite large and complex elements. A property which might be expressed as a line in the sense of reference 4, but which cannot easily be reduced to a string of characters.

So, where we get to is that one solution to the question posed at the beginning of this note, how do we distinguish a part from a property, would be to say that a property was a one dimensional object in two or three parts, all lines in the sense of reference 4, with the first being a reference to the object, in the case that the property was not embedded in the object, the second being the name of the property and the third being the value. We say nothing about the size of the elements involved. But we do say that both objects and their parts are something bigger, something occupying more space on a layer than a property. Parts are the same kind of thing as objects, while properties are not. At the extreme, anything which is not a line or a loop, although in practise we might expect most objects and parts of objects to be substantially bigger than a line or a loop.

We put aside the question of the division of labour between the name of a property and its value. So in the displacement example above, one might prefer to include the units of the displacement with the value of the property rather than with its name.

These arrangements might not satisfy a philosopher or a mathematician, but they might do for the purpose of defining a data structure from which we can generate subjective experience, an experience which does not need to respect philosophical or mathematical niceties. It just needs to be good enough.

Illustration

In the top half of the illustration we have a large blue ship, the dominant part, with three subordinate parts, all on the same layer. A representative object. The small pink rectangle is intended to remind us that the elements making up these parts, often sight mode elements, are small relative to the parts as a whole.

In the bottom half we have three properties.

In the first, the property is embedded in the substantive object, with both property and object on the same layer. With the property being a two part line embedded in the larger layer object, an arrangement which might be convenient in the case that the layer concerned is not driven by sensory data, where the geometry of parts is not otherwise important.

In the second and third, the property is linked to the substantive object on some other layer by the stubs on the left, with the weight being connected to the dominant part, here standing for the whole, and with the anthem, for some reason or other, being connected to the pink subordinate part. With these properties being three part lines, layer objects in their own right.

We will be saying more about all these arrangements in due course.

Conclusions

We have exhibited a way in which we might organise objects, parts and properties in our layered data structure, a way which maintains the reliance on geometry rather than on content or look-up tables. Put another way, we had already used the shape of elements to indicate their mode and we now use the shape of parts, parts which are made out of elements, to indicate their role.

References

Reference 1: http://psmv3.blogspot.co.uk/2017/03/a-new-start.html.

Reference 2: http://psmv3.blogspot.co.uk/2017/04/more-on-modes.html.

Reference 3: http://psmv3.blogspot.co.uk/2017/04/a-ship-of-line.html.

Reference 4: http://psmv3.blogspot.co.uk/2017/01/lines.html.

Group search key: srb.

No comments:

Post a Comment