Fuzzy types and fuzzy instantiation
Further exploration of
how we describe things
Copyright 2017 Graham Berrisford. One of about 300 articles at
http://avancier.website. Last updated 10/01/2021 18:27
This paper is about the fuzziness of descriptive types and instantiation of them.
Contents
Thing: a subdivision of the universe, locatable in space
and time, describable as instantiating one or more types.
Set: a collection of things that are similar in
so far as they instantiate (embody, exemplify) one type.
Type: an intensional definition, composed of
property type(s) that describe a thing.
Instance: an embodiment by one thing of a type, giving
values to the properties of that type.
Sign: a name, image or effect of a type, which
describers use in recognising, thinking or communicating about that type.
Token: an appearance of either a type or a sign, as
may be found in a memory or message.
The philosopher Wittgenstein looked for "family resemblances" across the range of things called "games".
He had a type name “game”, and he could define a wider genus (e.g. activity system) but could not find a specifically differentiating type property.
Family resemblances (edited from
Wikipedia 23/10/2017)
[In his later life] Wittgenstein grew uncomfortable with the traditional notion of category [type].
His discussion on the category game is particularly incisive (Philosophical Investigations 66, 1953):
“Consider for example the proceedings that we call 'games'. I mean board games, card games, ball games, Olympic games, and so on.
What is common to them all?
Don't say, "There must be something common, or they would not be called 'games' but look and see whether there is anything common to all.
For if you look at them you will not see something common to all, but similarities, relationships, and a whole series of them at that…
The result of this examination is: we see a complicated network of similarities overlapping and criss-crossing: sometimes overall similarities, sometimes similarities of detail.”
Since the publication of the Wittgentein’s “Investigations”, the notion of family resemblance has been discussed extensively.
Not only in the philosophical literature, but also, for example, in works dealing with classification.
The approach is described as "polythetic", distinguishing it from the traditional approach known now as "monothetic".
Prototype theory is a recent development in cognitive science where this idea has also been explored.
As the idea gains popularity, earlier instances of its occurrence are rediscovered e.g. in 18th century taxonomy, in the writings of Vygotsky or Tatarkiewicz.”
Prototype theory (edited from Wikipedia
23/10/2017)
“This was formulated in the 1970s by Eleanor
Rosch and others.
It is a mode of graded categorization in cognitive science, where some members of a category are more central than others.
It is a radical departure from traditional necessary and sufficient conditions as in Aristotelian logic, which led to set-theoretic approaches of semantics.
It leads to a graded notion of categories, which is a central notion in many models of cognitive science and cognitive semantics.”
Mathematicians define a set by defining its members in one or both of two ways.
Some sets can be defined by extension, by enumerating set members.
E.g. list the decimal numbers, or name the colours of the rainbow.
Some sets can be defined by intension, by typifying one member.
E.g. each member in the set of even numbers is as an integer divisible by 2.
Basic set theory is too limited for practical system description, because it assumes sets are static.
A static set cannot gain or lose members; add or subtract a set member and you change the set.
In most domains of knowledge, sets are dynamic, they grow and shrink: e.g. the set of trees, or bachelors.
A dynamic set cannot be defined by enumeration; it can only be defined by typifying a set member.
So here, a set is dynamic and defined with reference to a type.
Monothetic type: a type that defines properties necessary and sufficient to be a thing of that type.
E.g. A circle is a plane shape with a boundary equidistant at every point from a fixed central point.
The complement to a monothetic type is strict instantiation, where a thing completely and indisputably matches a type.
Polythetic type: a type that defines more properties than are necessary – so a thing need not instantiate all properties of the type.
E,g. A bird has feathers, a beak and the ability to fly.
If the bird type is monothetic, then penguins are not members of the set of birds.
If the type is polythetic, then penguins may be included in the set of birds.
A complementary idea is fuzzy instantiation, where the match of a thing to the type is incomplete and a matter of judgement.
The Stanford entry says that set theory is not enough to define a type.
“Even if types were sets, for example, set theory by itself will not answer the burning question of which set a species is.
One would then have to go to biology and philosophy of biology to find out whether a species is
· “a set of individuals closely resembling each other” as Darwin (1859, p. 52)
· a
set of “individuals sharing the same genetic code” as Putnam (1975, p. 239)
· a
set of “interbreeding natural populations that are reproductively isolated from
other such groups”, as Mayr (1970, p. 12)
· a
set comprising “a lineage evolving separately from others and with its own
unitary evolutionary role and tendencies”, as Simpson (1961, p. 153).
This article says that types emerged as bio-chemical symbolisations of things that recur and are important to an organism’s survival.
Fuzzy mathematics (after Lotfi Aliasker
Zadeh) is an even softer, fuzzier kind of typification, which feels closer to human reasoning.
In Boolean logic, the
values of a true/false variable are binary (yes or no, 1 or 0).
In fuzzy logic,
the values of a true/false variable may be any number between 1 and 0.
In other words, a thing can be partially true, or
have a degree of truth.
A thing can have rather more or rather less of a
quality, and it can be rather more or rather less a member of a set.
The type theory here doesn’t start from mathematics or software, it starts from Darwinian evolution.
This idea (that we describe particular things with reference to general types) is very important.
It is important not only in philosophy, mathematics and computing, but also in everyday human existence.
It is essential to remembering things and communicating about them.
|
Sign-type
pairs |
|
|
Sign
(and token) |
Type
(and token) |
|
Planet |
A large body that orbits a star. |
|
Even number |
An integer divisible by two with no
remainder |
In mathematics and computing programming (recent side effects of biological evolution) sign-type pairs are relatively rigid.
In natural languages, sign-type pairs are very much more fluid.
You and I associate many signs/words with somewhat different types.
And even in one mind, sign-type pairs evolve.
The fluidity and fuzziness of sign-type pairs explains many difficulties we have in philosophical discussion and in linguistics.
And the need for controlled vocabularies, or domain-specific languages, in scientific disciplines.
Those scientific disciplines include the design of human and computer activity systems that depend on information processing.
Designed thing: a thing described before it is created
E.g. what we may typify as a “motor car”, “accounting system” or “tennis match”.
Designed things follow types used to design them, whereas natural things precede types used to describe them.
Natural thing: a thing that emerges from the evolution of matter and energy, regardless of description.
E.g. what we may typify as a “planet”, “hurricane” or “penguin”.
Note that a natural thing's instantiation of a type cannot occur until that type is created.
We continually and inventively classify things, first this way, then that way.
In addition to descriptions we make of things, organic things are described and typified in the form of the DNA molecules from which they are made.
Fuzzy
biochemical typification
A Darwinian explanation of typification starts before mathematics and software, and even before words.
It starts from the notion that organisms evolved to recognise family resemblances between things (see the footnote 1).
A family resemblance occurs when the same properties appear in several things, or when a new thing resembles a past thing.
We do remember particular things, particular objects, particular events.
But does the brain work by comparing every newly observed thing with every remembered past thing?
The evidence is rather that brains store and recognise patterns of related sensations, or mental models of loosely-defined types.
And that recognising family resemblances gives organisms an advantage in the struggle for survival.
Animals recognise things of a type by fuzzily matching a thing’s observed properties to ones encoded in memory.
Consider the saying: "If it walks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck."
We might treat a thing as a duck even if has only two of the three properties (e.g. it cannot quack).
We might not treat a thing as a duck even if it does have all three properties (e.g. it is a mechanical model).
Fuzzy
verbal typification
Animals typify things to minimise
communication errors
The types of things recognised by animals are signified by the tokens they use to communicate.
E.g. an animal sounds an alarm call to signal a new instance of the type we call “danger”.
Natural language is loose; and in ordinary life we may find no need to formalise what the definition of a type.
But in complex or risky human endeavours, we need to minimise miscommunication errors between people.
And using the gift of verbal language, humans learned to formalise family resemblances in propositions like this.
E.g. A duck is a bird that waddles when it walks, swims by paddling its feet and quacks.
And/or formalise family resemblances in a type definition thus.
|
Type name |
Type definition |
|
Duck |
Bird, waddler, swimmer, quacker. |
Any type theory has to address two questions
If a thing does embody or exemplify all the properties in the type definition, must it necessarily be a duck?
Must a thing of the “duck” type embody or exemplify all the properties in the type definition?
Types
and the things that realise them – in general
A named type is a set of property types, which (wholly or partly) describe a thing of that named type.
A type defines a thing only in so far as that thing instantiates one or more of that type’s properties.
A thing can (wholly or partly) instantiate many separate types.
Things usually have many more properties than any given type; and may have less
It is a matter of judgement whether a thing that does not instantiate all properties of a type can be regarded as a thing of that type.
In software, an object is a thing that instantiates a description in a pre-existing class. No class, no object.
In biology, you might say an organism is a thing that instantiates a description in pre-existing DNA. No DNA, no organism.
But in most human experience, seeing a thing as an instantiation of a type is a conceptualisation, just as the type itself is a conceptualisation.
The strict instantiation
of a monothetic types in software engineering
The types we meet in software engineering are peculiar rather than normal.
A UML class is a relatively simple object type.
It is formalised the point where an instance is an object that:
· can be automatically manufactured by reference to that class
· must have values for all the properties of that class
The same applies to a whole computer program, even though it is a far more complex type.
Every instantiation of the program type is a strict performance of that program type.
Thinking of this kind misleads people about more natural typification.
Strict, perfect, conformance to types appears only in pure mathematics and software.
Aside: surely, no abstract type, no Platonic ideal form of a class or a whole program, existed before it was written?
Moreover, if you can erase all tokens of the type, then the class or program will disappear from the knowable universe.
Instantiation (strictly or fuzzily)
by things of types created in designing the thing
In a software system, a class is first designed, and then mechanically instantiated by objects.
An
object is an instantiation of one class, and
must have a value for each attribute of that class (if only a null value).
Each object attribute’s value equals
a value in the set of values defined by a data type.
Other kinds of designed thing depend on the prior existence of a description – if only in a mental model of the builder.
As soon as a designed thing (say a circus ring) is conceived, the possibility arises of building more objects that instantiate the same type.
However,
the relationship of type to instance is looser than between software class and
object.
In nature, types are abstractions that are recognisable and rememberable by organisms.
A type is a family resemblance that assembles other types into a type definition.
The instantiation of that defined type by real-world objects is fuzzy.
E.g. No circus ring is perfectly circular; yet we say it is circular.
E.g. Penguins cannot fly, yet we happily call them birds.
A fuzzy instantiation
of an apparently monothetic type: “circle
No real-world circus ring is perfectly circular.
An instantiation of the type “circle” is a (near enough) flat real-world shape that has (near enough) the same radius in all directions.
Aside: tokens of the “circle” type exist in countless mental, documented and other models people have made of things in the universe.
Surely, if you can erase all tokens of the type “circle”, then the concept will disappear from the knowable universe? Or do you believe otherwise? .
A fuzzy instantiation
of a polythetic type: a symphony performance
A symphony score is a complex type that typifies its performances, including rhythms, notes, intervals and instruments.
An instantiation of a symphony score is a performance of it, which fuzzily instantiates the type.
Aside: surely, no abstract type, no Platonic ideal form of the symphony, existed before it was written?
Moreover, if you can erase all tokens of the type, then the symphony will disappear from the knowable universe.
Instantiation by things of types used to describe it
The existence of a natural thing
does not depend on or require the existence of a type.
E.g. things of the "planet" type existed before any definition of that type.
E.g. things of the "duck" type existed before any definition of that type by humans.
Natural things instantiate types in our minds.
A thing can be called an instantiation of as many types as are used to describe it.
E.g. A duck is a thing that instantiates the types "waddler", "swimmer" and "quacker".
A natural thing embodies a value in the set of values
defined by a type.
E.g. a duck waddles, swims and
quacks.
E.g. a circus ring is measurably
circular.
Moreover, a thing cannot instantiate a type until that type is created.
E.g. For eons before mankind, the
thing we now call Pluto was neither named nor typified.
For a relatively short while, Pluto
was described as instantiating the type Planet.
Today, Pluto is no longer classified
as an instance of the type Planet.
A natural thing can instantiate or
embody zero, one or many types today.
It may in future instantiate new
types defined by humans.
And it may cease instantiating
types lost from all human minds and records.
Some regard types and type systems as the domain of software.
The definitions below are taken from the Unified Modeling
LanguageTM standard, v 2.4.1.
Note that two concepts can be related by a generalisation-specialisation relationship.
Instances of the more specific concept inherit all the features of the more generic concept.
E.g. squares inherit from rectangles, which inherit from parallelograms, which inherit from quadrilaterals.
And in UML, classes inherit from classifiers, which inherit from types.
UML Type
“A type constrains the values represented by a typed element.”
“A type serves as a constraint on the range of values represented by a typed element.”
“A type represents a set of values.”
“A typed element that has this type is constrained to represent values within this set.”
The value of a typed element must have a value that conforms to the type.
E.g. the type “rainbow colour” represents the set of values enumerated as {red, orange, yellow, green, blue, indigo and violet}.
A data item of that type must have one of those values.
UML Classifier
(inherits from Type)
“A classifier is a classification of instances, it describes a set of instances that have features in common.”
“A classifier is a type. A Classifier defines a type.”
“A classifier is a classification of instances according to their features.”
“All instances of a classifier have values corresponding to the classifier’s attributes.”
(Strictly speaking,
a classifier does not describe a set
of instances, it describes one
instance in a set.)
UML’s "classifier" is itself a generalisation of three subtypes:
· Component: components typify subsystems (and are akin to the systems discussed in these system theory articles).
· Data type: data types (e.g. integer and string) typify instances of data structures and data items, which are defined only by their value.
· Class: classes (discussed below) typify objects that have behavioral and structural properties.
UML Class (inherits
from Classifier)
“A class describes a set of objects that share the same specifications of features, constraints, and semantics.”
“The purpose of a class is to specify a classification of objects and to specify the features that characterize the structure and behavior of those objects.”
“Objects of a class must contain values for each attribute that is a member of that class.”
A software object instantiates a specific class; so the object’s existence depends on the existence of its class.
A class corresponds to the set of zero, one or more software objects that instantiate it.
Some see the class as being that set of objects.
But strictly
speaking, a class does not describe a
set of objects, it describes one
object in a set.
Multiple inheritance in
object-oriented programming languages
Multiple inheritance has two meanings.
It can mean one class inherits from another class, so an object instantiates one class directly, and others (its supertypes) only indirectly.
It can instead mean one object instantiates two or more unrelated classes.
The latter feels more like how types are used in natural language, and is akin to "mixin classes".
Mixins in
object-oriented programming languages
A mixin class contains behaviors that are "injectable" into other classes (https://en.wikipedia.org/wiki/Mixin).
A mixin may be described as being "included" in a class - rather than "inherited" from a more general supertype class.
Since mixins add properties to class, they don’t help us model the case where, for penguins to be birds, we need to subtract a property!
Type systems in
software
The main purpose
of a type system in software is to reduce miscommunication between two software
modules.
For example, once
a data item has been declared as an alphabetic name, a static type checker can
ensure it is not used in multiplication operations.
Various kinds of type system are discussed on this web page <https://en.m.wikipedia.org/wiki/Type_system>.
Structural typing is static typing, and checks type compatibility
by reference to all of a type's definition at compile time.
Duck typing is dynamic, and checks type compatibility by
reference only to that part of a type's definition that is referred to at run
time.
By definition,
dynamic type checking may cause a program to fail at runtime.
(In some
programming languages, it is possible to detect and recover from such failures.
In others, type-checking errors are fatal.)
All
free-to-read materials on the http://avancier,web site are paid for out of
income from Avancier’s training courses and methods licences.
If you find
them helpful, please spread the word and link to the site in whichever social
media you use.