Technical Editorial

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 99

We are delighted with the response to the last issue; letters and articles have arrived in sufficient profusion to enable us to base this issue’s technical section largely on your own contributions.

This issue introduces a new feature which we hope to continue on a regular basis — the technical letters section. We do not necessarily agree with all the opinions expressed by correspondents, but rather than make editorial annotations, we hope that you will write us letters with constructive criticisms instead.

In the next issue we shall be starting a new feature entitled ‘Surely There Must Be a Better Way?’ Readers will be invited to submit code where they suspect that there could be a better way of solving a problem, and we will publish any improvements that are received. If you do not know how to solve a particular problem in APL, send it in anyway and see if anyone has a solution. If you feel that you have a beautiful solution to a problem, send that in as well; if no improvements are published you will have the satisfaction of knowing that it may be the best. The problems should be short and capable of being solved with a single APL function. We do not intend to get into the business of writing complete packages.

The distribution of the inaugural issue of VECTOR was delayed, so we have decided to hold over the judging of the competition until the next issue. The responses so far have been numerous and excellent, and include an ingenious solution to beat the rules! Keep the entries coming in; you never know, you might make it.

One of APL’s problems is that it has a special character set that cannot be reproduced by most printers, as you have probably noticed whenever one of the computer magazines tries to print any APL. We made valiant attempts in the first issue of VECTOR to mix APL characters with ordinary text, which proved possible, but tricky, so we have now decided to make production easier by keeping any APL text on a separate line from other text. If you can keep to the rules set out below, you will increase the chances of your letters and articles being printed.

VECTOR Publication Standards for APL Code¶

In order to make the production of VECTOR easier, the following rules should be adopted when preparing letters, articles and other contributions for publication.

Please do not include APL symbols within the text. If an APL symbol needs to be referred to, use its name; most APL textbooks have a list of symbols and their standard names.

Where variable or function names are referred to within the text they will be set in ordinary capitals. This means that sentences have to be carefully worded so that a function or variable name can be easily distinguished from any other words that need to appear in capitals.

APL statements and function listings will be reproduced from the submitted document whenever possible, and will be pasted onto a separate line beween the text. This means that the listings should be of high quality; a ‘daisy-wheel’ printer with a carbon ribbon should be used. If you do not have a quality printer, we are prepared to re-set the APL ourselves if it is not too long, but we would much rather not do this as it is all too easy to make mistakes. Ideally we need two documents; the “readable” copy which shows what the final appearance is likely to be, and the “printer’s” copy which we actually send to the printers. The “printer’s” copy needs to have all the APL completely separated from the text. The easiest method is to leave three blank lines in the text where the APL is to appear, and to have a separate sheet containing all the APL; each section also separated by three lines. A simple numbering scheme can then be used to show where the APL block is to appear in the text. These APL characters will be photo-reduced and inserted into the text body.

Drawings, figures and black and white photographs are welcome, as they help to break up the text and make articles more visually interesting. Please prepare each figure on a separate sheet of paper, and give it a number and caption. The caption will be typeset and will appear at the top of each figure, which will be presented in a box as near as possible to the reference in the text. Do not worry about the size of the drawing, as the printers will photo-reduce it to fit the size of the page or the space available. Your text should refer to the drawings strictly by sequential figure numbers.

Footnotes and references will be grouped together at the end of the article, so please avoid writing text that requires a footnote to be on a particular page.

Introduction to Contributed Articles¶

In this issue we are presenting four contributed articles.

“APLpip — the hard seed of a health-and wealth-giving fruit” was originally sent to us by Mr. Llewellyn-Jones as a letter. We have converted it into a technical article. Program listings were also included, but were unsuitable for reproduction. Mr. Llewellyn-Jones, who works for Reuters in London, tells us the story of how he has attempted to solve the problem of representing APL code using the standard ASCII character set. We would particularly like to hear from others who are working in this important area.

Professor Alan Hawkes of the department of Management Science and Statistics at University College, Swansea has contributed two articles. The first, “Statistical Computing with APL” is reproduced with the kind permission of ‘The Professional Statistician’. Although intended for a statistical audience with no knowledge of APL, it also serves as an excellent general introduction to the language.

Professor Hawkes’ second contribution, “Numerical integration and probability distribution” presents an APL function that employs Simpson’s rule for the numerical integration of any well behaved function. It is implemented in MIPS APL on a PRIME 750 and its use is demonstrated by calculating probabilities from the distributions used in statistics. It is claimed that the results are accurate and efficiently computed. We are most grateful to Professor Hawkes for his articles and look forward with interest to the continuation of the geometrical progression represented by the volume of his contributions.

Finally, in “ISO APL Standard Update”, David Ziemann, one of the Technical Editors and a consultant with Cocking and Drury, gives a brief update on the state of the ISO APL standard as a result of the last meeting of the working group in Helsinki just after APL 84.