Technical Correspondence (Bowman)
Vector 3:1, page 99
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 99
From Dick Bowman¶
Sir:
Incorporated into a graphics package there’s the following little snippet of code associated with curve-fitting:
There are a few twiddly bits around it to ensure that it doesn’t fall over too frequently because the user has total control of data values Y and X and of the order of the fitted curve – in the worst case the embedding function reverts to joining the points with a set of straight lines.
Curious as it may sound this had been working fine for some years in a VSAPL/VSPC environment and also in an APL*PLUS/PC incarnation; however implementation in APL2/TSO resulted in a series of phone calls along the approximate lines of “’ere, why are my curves all jaggy?”. So with a sample set of data to hand we take a look at what goes on in the three incarnations:
Strange as it may sound, our user wanted to fit a third-order curve to this, so let’s look at
Y⌹X∘.*0 1 2 3
¯6159617.48 92648.90706 ¯46.47206775 0.007770014433 ⍝ VSAPL
¯61569559.53 92648.8197 ¯46.47202385 7.77000708E¯3 ⍝ APL*PLUS PC
DOMAIN ERROR ⍝ APL2
A fascinating finding; further investigation shows that there is a reasonable agreement between the three cases for orders less than three, and when we go to higher orders both VSAPL and APL*PLUS/PC refuse at six, agree with one another moderately well at four, but diverge wildly at five. Which gives us a potentially very interesting situation that with the same data and the same code within the functions, we can end up with three totally different graphs depending on which system we use to draw them.
Let’s come to some conclusions:
- a)
- Given sufficiently perverse data there’s something different about the domino algorithm in APL2;
- b)
- Letting end-users choose the order of a fitted curve is a nice idea in theory and essential sometimes, but quite often all they want is for it to look nice and smooth;
- c)
- Sometimes a little thought about algorithmic subtlety can repay itself in avoidance of nasty surprises.
Yours sincerely,
Dick Bowman,
C.E.G.B.,
85 Park Street,
London, SE1.
(Editor: The draft ISO APL standard specifies that the algorithm to be used for matrix-divide is implementation-defined. Although no sensible implementer would use an algorithm other than matrix division, it does allow implementers to use different variations of the general technique. This means that different APLs can produce different results and yet still conform to the standard. An acceptable algorithm for matrix division can be found in “Domino – An APL Primitive Function – Its Implementation and Applications”, from Quote-Quad Vol.3, No.4, February 1972.)