One might expect from the title of this paper and its place of publication that it would contain material on automatic programming, signal processing, and pattern recognition. But the reader would be sadly disappointed on all three counts.
The paper describes a system which will take a graphical representation of an algorithm and, following manipulation by a screen editor, either undertake a performance analysis or “complete” the algorithm design and generate object code, thus enabling the algorithm to be executed. The paper is largely written in the future tense, since significant parts of the system have not yet been produced. Indeed, if the full system had been available, many interesting technical details could have been included instead of a vague mention of the author’s intent.
Lack of detail and (almost consequentially) a lack of references makes technical appraisal of the paper impossible. However, certain general points must be made:
The proposed system hardly constitutes an automatic programming system; the user provides the basis of the algorithm, rather than a specification from which an algorithm is to be extracted. What is envisioned is a translation system with a graphical frontend.
The use of templates to translate from high-level representation of algorithms improves reliability of the resultant code, but this code is not renowned for its speed; and speed is very important in realtime signal processing applications.
The author cites signal processing as a good application area for the kind of system he is proposing because of the structural simplicity of the algorithm- s. If this is so, then why do we need elaborate systems to encode more (simple]) algorithms?
One option open to the user is to ask about performance of the algorithm under development. It is suggested that, independent of the target machine (or language)--and, by inference, based only on the LISP-like pseudocode--the system can estimate the space required by the resultant code and say something useful about time. Referring again to the application area, it is sure that, provided that space usage is reasonable and hence costly data accessing modes can be avoided, execution time is of premier importance. However, little can be said about this at the intermediate-code stage of translation.
In conclusion, I feel that the author has put pen to paper far too early. If he really needs to use pattern recognition techniques within the initial input phase of the system (as opposed to icons, etc.) then maybe he could write up that part of the project. Such a paper would perhaps be of more substantial interest to the readers of the journal.
