prev "Autoformalisation - Knowledge acquisition of professional skills" by Gregory Gromov,
   Microprocessor Devices & Systems, Moscow, 1986, N 3, p.80--91, Chapter 7


Required Tools, Method Efficiency Evaluation, and the Limits of Applicability...

Like any other purely speculative illustration the above example is vulnerable on many fronts.

One might reasonably object, “We can suspend our disbelief and imagine that a man from the country might put aside his gun for a while in order to have fun with a computer and a game package. But to imagine him writing a program in real-time?"

“Are you sure that the process of autoformalization, as you choose to call it, will not require the same lifelong time frame?” another opponent might ask, smiling sympathetically.

Finally, the third objection—”What makes you so sure that after two or three successful runs, the vehicle controlled by such a program will be able to make the same trip even once more? What will happen at a different time of day? Or in different weather?...”

The first question should clearly be addressed to professional programmers, who write basic software in order to provide the autoformalization process with the necessary programming tools. In this connection we would like to emphasize once again the importance of further developing the concepts of ‘object-oriented’ programming, according to which application-oriented basic tools should be created before the user starts working with the PC. These tools should make it possible for the end user to independently program relatively complicated regular production processes, including real-time processes, by only carrying out the necessary and natural action dictated by previously-acquired professional experience, actions ‘in the world of information objects’ displayed on the computer screen.

 Such programming by intuition comes close to the process of controlling plot development in computer games.

The meaning of the second question would probably be clearer if we remember the well-known saying that in principle, anyone can become an academician: It might take one person thirty years, whereas another might need three hundred... It goes without saying that any non-professional programmers will be unable to formalize any applied problem using personal computing. As a Japanese expert noted, “to sell personal computers saying what they can do is the same as selling pens stating that with their help one can write a masterpiece worthy of the Akutagawa or Nobel Prize.”

A specialist in a certain field with a PC at their disposal for formal recording of the actions he or she takes can, in certain conditions, record in computer codes a trace of the production process he or she is supervising. It is often possible even in those cases when there is practically no other way for a layman to gain insight into what the professional is doing. However, there is no ‘predestination from on high’ for any separate attempt at professional knowledge autoformalization, and there cannot be any. Today we have at our disposal nothing but the experience gained by millions of users over the last few decades of the computer era. This experience definitely shows that the probability of successfully solving professional problems, which are difficult to formalize, is generally much higher when a specialist in a given field is starting with the object of automation before moving to the computer than it is when a professional programmer is moving from the computer to the process being formalized. As far back as the early 1970s, when the first attempts were made to introduce microcomputer automatic control systems, US computer experts had to admit that "it is more difficult for us to understand how an automobile company is functioning than it is for them to understand the operation of our microprocessors“.

And finally, the third question: Naturally, there is absolutely no guarantee that the navigation program created by the hunter will successfully pilot the vehicle next time, no matter how many previous trips were successful! Moreover, it was our desire to demonstrate the limits of the rational application of knowledge autoformalization methods that made us choose such an exotic example.

The main problem in this case is not even the fact that even complicated programs normally get stuck when applied in a new area—the crux of the matter is something else entirely. It is well-known that even underground, with its maximum stability of both route and meteorological conditions, nobody risks going without a driver... Automatic devices play only a secondary part even there. It is quite clear that only human production activities devoid of dangers can serve as a sphere of application for professional knowledge autoformalization methods. We shall explain what this means with the help of a very simple example. Let us assume that there is a database for computer-based storage and prompt retrieval of documents that had previously been kept in the desk drawers of their authors. Let us also assume that the PC user retrieves certain documents using the desktop analogues so ubiquitous these days, which means that the user sees images of various folders on the computer screen. The user can remove files from these folders using the cursor, and he or she can sort through office files until they find the required document. Using ‘object-oriented’ programming methods, the user can program various search algorithms to retrieve the data he or she may need, including algorithms quite similar to the heuristic ones he used in the pre-computer era.

 The total area of human professional activity that can be in principle formalized and consequently automatically controlled by computers is figuratively speaking only a thin film of formalized knowledge, slightly covering the surface of the ocean of non-formalized knowledge accumulated by human culture. 

Many office workers have more than once heard the request of a colleague obliged to leave his desk for a while: "Do not touch my papers, please, or I won’t be able to find anything!" How does a person normally find the required document in the chaos of desk drawers stuffed with various papers? Evidently, few people seriously asked themselves such questions. But if the same office worker, as a result of a long autoformalization process, manages to ‘teach’ his search algorithm to a computer, and if the resulting program makes it possible to immediately retrieve the required document in 60% of cases, this means that a considerable rise in efficiency has been achieved at this workstation. Naturally, in the remaining 40% of cases, when the program would not help, nothing too serious will happen and pseudo-manual retrieval will be carried out. In comparison, even a small probability of failure in piloting the cross-country vehicle is unacceptable because of the destruction such a failure would cause.

If professional knowledge autoformalization managed to reduce the portion of manual operations at a certain workstation by 30 to 40 percent, in most cases this would mean a considerable rise in labor efficiency, which would cover the cost of PC installation. If in the remaining 60 to 70 percent of cases the program proves to be of no use and the operator has to perform the task manually, as was the case above, this only means that at this workstation it is still impossible to take into account all necessary factors involved in the complicated production process. Applying the traditional ‘all or nothing’ choice in the evaluation of an application program’s usefulness is out of place in this case, as the ratio between the number of successful runs and failures is but a current index of the achieved rise in labor efficiency. The situation is quite different when a failure can cause serious damage. That is why areas of application where crises are possible must be the main focus of so-called ‘demonstrative programming’.

Thus, for a strict demarcation between the spheres of application of mathematically irreproachable ‘demonstrative’ programming, performed exclusively by professional programmers, and the process of knowledge autoformalization, involving ever growing numbers of ‘para-programmers’—the most numerous category of PC users—it’s worth reviewing the three well-known laws of robotics, as laid down by Isaac Asimov: 1) under no circumstances may a robot harm a person; 2) a robot must not harm himself or other robots, if it does not contradict the first law of robotics;  3) a robot must carry out any instruction given by a man, as long as it does not contradict the previous two laws.

It is obvious that the use of a program made using professional knowledge autoformalization methods is only acceptable if the third law of robotics is satisfied. To provide for absolute adherence to the first law and to minimize the risk of violating the second—such is the work of ‘programming to order’, performed by professional programmers working with maximum rigor.

Now, going back to the transportation problem, let us assume that in a shop with a multi-tiered system for controlling production processes it is necessary to program the route of movement for a vehicular robot, while allowing frequent route changes. A great number of such robots working in the shop simultaneously would minimize the idle time for the machines waiting for blanks. Let us also assume that before the introduction of this fully automatic system,  the  trucks with experienced drivers were employed in the shop, which prevented too long time   idleness of the equipment.

In other words, we again return to the hunter problem. But this time we must start by making sure that the first two of Asimov's laws are observed. The vehicular robot should be first of all be equipped with firmware completely excluding the possibility of the robot running into a person, other shop equipment, or another robot. After the safety requirements have been satisfied, the application-oriented programming system provides the truck operator with the required means of testing various routes in, say, computer gaming mode.

Let’s say that the first version of the program will only take the robot to the end of the route successfully in 40% of attempts. This means, in the first approximation, that only 70% of the previously-engaged truck operators will be needed to supply the same amount of blanks as were previously supplied by the whole team. Presumably, 10% of personnel will now be doing nothing else but finding the robots that got lost and bringing them back to the starting point. When the program is improved and the probability of the robot following the optional route to the end reaches 60%, for example, that will mean that almost half of the truck operators can be released, and so on.

The above example serves to stress once again that different criteria should be used in evaluating a program created in personal computing and those professional programming products made to order. The latter’s value should never be considered before a safety certificate is issued, certifying that the program has successfully passed all the required tests. On the other hand, the product of professional knowledge autoformalization often proves locally useful long before the final version of the program is accepted. Moreover, for many programs of this type, the aim of reaching a reliability of nearly 100% may be considered economically meaningless, whereas a program which is successful in less than half of practically interesting cases may give an appreciable rise in labor productivity at a given workstation.

Different objectives, different technologies, different applications, and, consequently, quite different criteria used in evaluating the quality of professional knowledge formalization.

Thus, the notion of formalization acquires a fundamentally new meaning, going far beyond the rigid deductive and logical framework in which it formed for the first 25 centuries of development of the classical branch of mathematics that prevails today.

The success or failure of knowledge formalization is now often determined by essentially new, pragmatic criteria (economic criteria, for instance, as shown above) rather than by its level of logical demonstrativeness. In other words, with expanding computer applications, it becomes common that two notions traditionally inseparable since the time of Pythagoras of Samos’s knowledge mathematization—formalization and logical demonstrativeness—are no longer linked.

This fact was alluded to above when we said that with mass introduction of knowledge autoformalization technology the very notion of formalization is being transformed.



 "Autoformalisation - Knowledge acquisition of professional skills" by Gregory Gromov,
   Microprocessor Devices & Systems, Moscow, 1986, N 3, p.80--91, Chapter 7

  Copyright © 1986-2011 Gregory Gromov