Windills

M Computing, Volume 3, number 2, April 1995, pages 40-41

MDC Accepts Set of Extensions
by Ed de Moel

I am writing this column in the airport of Albuquerque, New Mexico. Over the past week, I have been at an MDC meeting, and I have experienced too many kinds of different weather to count: freezing cold at night, snow in the morning, nice toasty weather while strolling around Old Town to get lunch, and rainstorms; and that all in the course of one day.

Sitting down after such a meeting, one asks oneself: what did we accomplish? At first, the proceedings leave such an overwhelming impression that it hardly feels like anything ever got to closure, and then it all starts to fall into place. About 30 taskgroups met for four days. Dozens of proposals for modifications to the M[UMPS] language were discussed. Some for the first time, some for the last, but most are at the stage that we're trying to figure out exactly how we want to do things. Some proposals just sail through: at the first meeting that those ideas are introduced, everyone agrees that one approach is the right way to do it, then there are two more meetings spent on writing the text that is going to be inserted into the next revision of the standard, and the following meeting, it just gets accepted without much discussion.

If only all were that simple... Often it occurs that, at the first discussion, everyone agrees that an extension to the language should work in a specific way, and then people start playing with the idea and things that seemed self-evident at first appear to be inconsistent with behavior elsewhere in the language. And that's when it starts to look like the storms outside carry over into the meeting-rooms... That is when it takes years and years before an extension finally makes its way through the process and is approved for inclusion in the next standard. A good example of this is the command that will create a M[UMPS] routine. ZSAVE, FILE, ROUTINE, RSAVE; there have been many, many approaches to the concept. It seems so straightforward, yet there are so many opposing possible strategies of making things work, that the committee has been trying to reach a concensus since as early as 1981, and still we're not done.

One set of extensions that did reach completion at this meeting is the collection of mathematical functions that will be available through the math library. There are 44 new functions: ABS, DECDMS, DEGRAD, DMSDEC, E, EXP, LOG, LOG10, PI, RADDEG, SIGN, SQRT, SIN, COS, TAN, COT, SEC, CSC, ARCSIN, ARCCOS, ARCTAN, ARCCOT, ARCSEC, ARCCSC, SINH, COSH, TANH, COTH, ARCSINH, ARCCOSH, ARCTANH, ARCCOTH, CABS, CADD, CCOS, CDIV, CEXP, CLOG, CMUL, COMPLEX, CONJUG, CPOWER, CSIN and CSUB.

The good news is that the calling mechanism for all of these will be portable, starting from the next standard. The bad news is that, while for most people "next" means the standard that is currently in the canvass process, for the MDC "next" means the one after that. The deadline for inclusion in the standard that is now being canvassed elapsed in June 1994, when the canvass document was mailed to all instutions on the canvass-list. So we will have to wait another 4 to 5 years to see a standard that actually contains these functions. Nevertheless, SET X=$%SQRT^MATH(2) will soon be standard M[UMPS], and the implementors will probably start to offer it long before that new standard will be printed.

$%SQRT^MATH, you ask? ^MATH? Does that mean that a routine will need to be loaded every time a math function is called? Not necessarily. The prefix $% signifies that the rest of the reference is to a standard library function (SQRT is the name of the function, and MATH is the name of the library). Although the various implementors will each have their own way of supplying standard libraries, there will certainly be much less of a performance penalty for calling $%SQRT^MATH than there would be for SET X=$$SQRT^MYOWN, and the library function will typically be more accurate than a function written in M[UMPS] would be.

Now, in M[UMPS] we could always abbreviate everything to its first letter; can we still do that with those new library functions? No, it wasn't possible to define the library functions in an unambiguous way and retain this option. Both the name of the function, and the name of the library will have to be spelled fully.

A first at this MDC meeting was a set of responses by the Interpretations Task Group. This group was created to answer questions about the standard. The notation and language in the standard have evolved to the point where certain parts are no longer easy to understand for everyone. If ever you don't understand what is intended in the standard: "Just Ask!" The Interpretations group is there to answer.

The questions this time:

• In counting the number of characters in the name of a global variable, do you include the leading ^ sign? No, that character doesn't count toward the maximum number that is portable.
• For values between 1 and +1, should the two-parameter form of $FNUMBER produce a leading zero, just as it does for the three-parameter form? No, that zero only appears when the third parameter is specified.
• What is the sign of 0 (zero); is zero negative or positive? Zero does not have a sign. It is not positive, nor negative.
• How is the naked indicator affected in the context of SET $EXTRACT(^D(4,^A(1)),1,^B(2))=^C(3)?
• The references that affect the naked indicator are, in sequence: ^A(1), ^B(2), ^C(3) and ^D(4,a), unless the value of ^B(2) is less than 1, in which case the reference to ^D never occurs.
• And, finally, what is the meaning of the term standard in the definition of library functions?
  The term standard was introduced to simplify (sic!) the description of the values that a function can return. It means that the possible values are all that are typical for the data interpretation (tangent would return a standard value, sine is limited: -1 ≤ value ≤ +1).

Ed de Moel is past chairman of the MDC and works with Jacquard Systems Research. His experience includes developing software for research in medicine and physics. Over the past ten years, Ed's has mostly focused on the production of tools for data management and analysis, and tools for the support of day-to-day operation of medical systems. Ed can be reached by e-mail.