IDEAL

Iterative Dialectic Engine for Automated Learning


The distinction between data and control

barber paradox.  A paradox illustrating a problem in set theory.  Suppose that the barber of Seville shaves all the men of Seville, except those who shave themselves.  Does the barber shave himself?  If he does shave himself, he is not to be shaved by the barber, that is, himself;  if he doesn't, he should be shaved by the barber.  Hence he both does and does not shave himself.  So the original supposition is false. (1)

Relational databases are based on set theory, as expressed by Codd's Laws.  What happens to the barber paradox when the men of Seville are listed in a database table?  For example:

Name

Trade

Shaved_by_barber

Aurelio

Banker

Yes

Bartolo

Baker

Yes

Cesar

Beggar

No

Domingo

Baritone

Yes

Eloy

Butcher

Yes

Figaro

Barber

No

(The choice of record entries is arbitrary and may be varied.  No-one shaves Cesar the hairy beggar, however.)  The following SQL script identifies those men of Seville who are shaved by the barber:

SELECT Men_of_Seville.* FROM Men_of_Seville WHERE [Men_of_Seville].[Shaved_by_barber]=True;

The result of this query:

Name

Trade

Shaved_by_barber

Aurelio

Banker

Yes

Bartolo

Baker

Yes

Domingo

Baritone

Yes

Eloy

Butcher

Yes

No paradox!

One can try any combination of record entries and the result is the same:  those men of Seville that are shaved by the barber, are shaved by the barber;  those that aren't, aren't.   In particular, if the barber is shaved by the barber, then he is shaved by the barber;  if not, not.  There is no paradox because the database does not know that it is the barber who shaves all the men of Seville, except those who shave themselves.  Neither is it simply a matter of imparting this fact to the database, firstly because there is no obvious way of telling it, and secondly because the database wouldn't know what to do with the information even if it had it.  We relate the data record 'Barber' with the operation 'shaves all the men of Seville, except those who shave themselves', but the database does not and cannot.  The database draws a clear distinction between data and operators - as do all computer programs, for that matter.  The distinction is simple:

Thus operators may be treated as items of data, if referenced by name only, but items of data may never be treated as operators.  The barber paradox arises because we fail to make this distinction.  And it is our failure:  the distinction between data and operators is as fundamental as Hume's law ("You can't get an 'is' from an 'ought', or vice-versa");  and the phenomenal development of computer technology would not have been possible if its pioneers had felt the need to take account of the barber paradox and its kin - Russell's paradox, the liar paradox, and so on.  These are not paradoxes but fallacies.  It is left to the reader to consider the consequences of this statement on, for instance, Russell's critique of Frege's system of logic, or Gödel's incompleteness theorems, derived by reducing data and operators alike to sequences of numbers.  For present purposes it is sufficient to conclude that any design of an automated learning engine must be able to distinguish between data and operators.  It follows that, in the transfer of information between program components, it is necessary to distinguish between data (comprising information only) and control (comprising a command or set of commands).

References

  1. Antony Flew (ed.), A Dictionary of Philosophy (Pan 1979).

Click here to go back


Copyright © Roger Kingdon 2004