Logic Programming as a Side Show

Appeared in Volume 6/3, August 1993

Keywords: applications.

Maarten van Emden

For researchers in logic programming, their subject is the centre of the world. This is probably true of researchers in other topics. But the trouble that logic programming seems to be having in finding a useful place in the world may have to do with the fact that their practitioners have a special problem in understanding the world around them.

This was certainly the case for me. Here I relate an experience that helped me to get a better idea of the lay of the land outside of logic programming. My starting point was that excellent paper 'CLP(R) and Some Electrical Engineering Problems' by Heintze, Michaylov, and Stuckey in the Proceedings of the Fourth International Conference on Logic Programming. It contains the following program to compute a simple trajectory:

traj[_,_]).
traj([Hm,H,Hp|T]) :-
  (Hp-H)=(H-Hm)-G, G=1,
  /* Change in height differs by gravitation velocity change */
  traj([H,Hp|T]).

?- H1=0, h10=5, traj([H1,H2,H3,H4,H5,H6,H7,H8,H9,H10]).

This program works on a list of heights at horizontal coordinates that are a constant mesh width apart. It generates a linear equation for each of these (well, almost each), which are then solved by the constraint solver. It seemed to me spectacular that all one needed to do was type in a clear and succinct definition of the problem and the solution was then only a single key stroke away.

When I showed this to my engineering friends, they were certainly polite. Pressed to explain why they thought this so useless, they told me that in their area they certainly used linear models a lot, but that they were always up against the limit of what their computers would allow. They thought it unlikely that a generic linear equation solver would satisfy their requirements. They squeezed the most out of their facilities by using a specialized routine that had proved most effective for the type of linear equations involved. Usually this type is determined by the application. Thus, though mathematically the problem is the same, that of solving a set of linear equations, it is essential to know whether the system belongs to the important subclass of symmetric positive definite systems, whether it has a band matrix, a block matrix, or is sparse in some other way. Certain problem features determine whether it is wise to try an iterative method. Some of the engineers were even so idiosyncratic in their requirements (finite element analysis) that none of the dozen or so state-of-the-art packages was good enough.

If I would then have discarded the example from Heintze et al. it would have been an extreme case of throwing out the baby with the bath water. There is something extremely valuable in that tiny program. But the value is not that the whole problem can be solved by only typing in the problem description. It turns out that the engineers have their own blind spots. For them the centre of the action is setting up the linear model. They have learned to realize that solving the equations is also something that is only underrated at one's peril. But most engineers disregard a certain annoying problem that success in computing has brought.

Because of the power of current computers and solving algorithms it is possible to solve systems of linear equations with over a thousand variables. This means that an engineering design has to be translated into over a thousand of numbers. Each of these has to be typed correctly and has to find the right slot in the input of the equation solver. Not only does this have to be done right, it has to be seen to have been done right. Engineers neglect this aspect not so much because they don't realize how dangerous and expensive it is, but because their methods don't suggest how to do anything about it.

Now look again at the above example. It combines to stages: setting up the linear equations and activating the solver. The combination is, in serious applications, fortuitous. The first stage solves an urgent practical problem. The second stage makes for a nice demo, but should not lead one to think that the two stages are necessarily coupled.

Strooper, Stylinaou, and Tabarrok ('Prolog for Finite Element Model Definition,' Proc. ASME Computers in Engineering Conference, 1992) followed the first stage of the example and wrote in Prolog and CLP(R) descriptions of truss structures (the load-bearing skeletons of highway bridges or tall buildings are examples) that generate input to an existing program for finite element analysis, thus obviating the need for tedious and error prone translation of the design to numerical input. The engineers considered this extremely useful. Yet, the logic programming component is very much a side show: the finite element analysis program is much more important (because it's harder to do without), eats up much more memory, and takes up much more computing time.

All over engineering, science or operations research, there are designs or models with a succinct description. These need to be translated to large amounts of numerical data that are fed to special purpose state-of-the-art software packages. There is much opportunity here for similar front ends written in Prolog or CLP(R). And I suspect more opportunities lie in wait for those in our field who realize that theirs is not the centre of the world and who are willing to participate in productions where they are no more than one of the side shows.

Maarten van Emden
Dept. of Computer Science
Univ. of Victoria, Victoria, B.C., Canada V8W 3P6
Email: vanemden@csr.uvic.ca