User:Dinosaur: Difference between revisions
No edit summary |
m (Oops.) |
||
| Line 24: | Line 24: | ||
The COBOL programme would read text into variables A and B, set values into x and y, and if A was "numeric" and B was "numeric", proceed. Alas, I was unclear on the distinction between programme source statements, and run-time compiled code. There are of course many languages whereby exactly this would work, possibly with the introduction of something like an "evaluate(A)" statement, but, COBOL is not one of them. Ah well. |
The COBOL programme would read text into variables A and B, set values into x and y, and if A was "numeric" and B was "numeric", proceed. Alas, I was unclear on the distinction between programme source statements, and run-time compiled code. There are of course many languages whereby exactly this would work, possibly with the introduction of something like an "evaluate(A)" statement, but, COBOL is not one of them. Ah well. |
||
In 1970 at Auckland University, the Applied Mathematics class introduced the AMI computer, a decimal computer with a thousand five-digit words of storage, which one programmed in machine code only, thus learning about the bootstrap, the loader and the relocating loader, as well as writing |
In 1970 at Auckland University, the Applied Mathematics class introduced the AMI computer, a decimal computer with a thousand five-digit words of storage, which one programmed in machine code only, thus learning about the bootstrap, the loader and the relocating loader, as well as writing assembler programmes to calculate sin(x), etc. with Tschebychev polynomials used to spread the accuracy more evenly and with fewer terms though odder coefficients. This computer was actually manifested via an interpreter on an IBM1130. We were also introduced to Fortran IV, and could have actual operating access to its predecessor, an IBM1620 which worked in Fortran II. Later that year I wrote an interpreter for the AMI system for the IBM1620, and thereby won four milkshakes from a friend, Michael Dowling, who took the AMI course the following year and used my programme for test runs. On one of his assignments, he had difficulty and test runs were facilitated by the immediate feedback. I happened by, and the discussion went somewhat as follows: |
||
"It will work." "No, it won't" - first milkshake. |
"It will work." "No, it won't" - first milkshake. |
||
| Line 34: | Line 34: | ||
Over the Christmas holidays I gained money instead of milkshakes: employed by the computer centre to write a data-checking system in Fortran, plus my first introduction to IBM1130 assembler. |
Over the Christmas holidays I gained money instead of milkshakes: employed by the computer centre to write a data-checking system in Fortran, plus my first introduction to IBM1130 assembler. |
||
In 1972 the family moved to Wellington on my father's promotion to Chief Surveyor, and so to Victoria University where we students had access to the IBM1130 and Clive Nicolson was the pre-eminent expert and the same height as me - 6'4" so we could not |
In 1972 the family moved to Wellington on my father's promotion to Chief Surveyor, and so to Victoria University where we students had access to the IBM1130 and Clive Nicolson was the pre-eminent expert and the same height as me - 6'4" so we could not overlook each other. We got stuck in to the operating system and miscellaneous device drivers, none of which had much to do with our course work, which had little to do with computers or the likes of tables of prime numbers, or e calculated to 132,800 places. Thus, the analysis of the results of a physics experiment might be facilitated by using a computer programme, but using computers was not a part of the course. In other words, unlike computer science courses where the programme is assessed on aesthetic grounds, these programmes were written to produce results, and correct ones at that. This proved to be an employment advantage. |
||
Revision as of 10:36, 4 October 2015
| My Favorite Languages | |
| Language | Proficiency |
| ALGOL | Rusty |
| APL | Rusty |
| Pascal | Active |
| Delphi | Rusty |
| BASIC | Rusty |
| Fortran | Active |
| COBOL | Very Rusty |
| DOS | Rusty |
| MATLAB | Active |
| Octave | Active |
| PL/I | Rusty |
| R | Active |
| SNOBOL4 | Very Rusty |
| C | Very Rusty |
| JCL | Very Rusty |
It was great when it all began
Long ago, the Reader's Digest Young People's Annual for 1963 had an article by Martin Gardner on a simplified form of chess called Hexapawn to be played on a three by three board, and how to build a computer out of two dozen matchboxes that learns how to play the game. Each matchbox bears a diagram corresponding to a possible board position and has coloured arrows for the moves that can be made from that position. Within are smarties corresponding to the arrows, and when a particular move is determined to be bad, its smarty is devoured...
At Hutt Valley High School, the Physics master had in 1968 a contact with Balm Paints, whereby we pupils could write a programme for their IBM360, and we were set the task of solving A*X + B = C for given values of A, B, and C. In COBOL. Inspired by this, and vexed by the mathematics classes that incessantly set us to making sketch plots of various arbitrary functions, I thought of a way of having the computer doing the work. The idea was to have a sketch pad of 120 by 60 character positions (a lineprinter page), and with suitable scaling say from -6 to +6 for character positions 1 to 120, etc, have the computer consider an expression A(x,y) = B(x,y) for the 120 by 60 possible spots and if the LHS and RHS differed by less than 1, say, for some (x,y) = (column,line) place a splot to be printed. Thus, a LHS expression might be A = "y" and the RHS expression be B = "3*x**2 + x - 6"
The COBOL programme would read text into variables A and B, set values into x and y, and if A was "numeric" and B was "numeric", proceed. Alas, I was unclear on the distinction between programme source statements, and run-time compiled code. There are of course many languages whereby exactly this would work, possibly with the introduction of something like an "evaluate(A)" statement, but, COBOL is not one of them. Ah well.
In 1970 at Auckland University, the Applied Mathematics class introduced the AMI computer, a decimal computer with a thousand five-digit words of storage, which one programmed in machine code only, thus learning about the bootstrap, the loader and the relocating loader, as well as writing assembler programmes to calculate sin(x), etc. with Tschebychev polynomials used to spread the accuracy more evenly and with fewer terms though odder coefficients. This computer was actually manifested via an interpreter on an IBM1130. We were also introduced to Fortran IV, and could have actual operating access to its predecessor, an IBM1620 which worked in Fortran II. Later that year I wrote an interpreter for the AMI system for the IBM1620, and thereby won four milkshakes from a friend, Michael Dowling, who took the AMI course the following year and used my programme for test runs. On one of his assignments, he had difficulty and test runs were facilitated by the immediate feedback. I happened by, and the discussion went somewhat as follows:
"It will work." "No, it won't" - first milkshake.
"This time it will work." "No, it still won't" - second milkshake.
"I suppose it won't work." "Yes it will!" - this time, double milkshakes.
Over the Christmas holidays I gained money instead of milkshakes: employed by the computer centre to write a data-checking system in Fortran, plus my first introduction to IBM1130 assembler.
In 1972 the family moved to Wellington on my father's promotion to Chief Surveyor, and so to Victoria University where we students had access to the IBM1130 and Clive Nicolson was the pre-eminent expert and the same height as me - 6'4" so we could not overlook each other. We got stuck in to the operating system and miscellaneous device drivers, none of which had much to do with our course work, which had little to do with computers or the likes of tables of prime numbers, or e calculated to 132,800 places. Thus, the analysis of the results of a physics experiment might be facilitated by using a computer programme, but using computers was not a part of the course. In other words, unlike computer science courses where the programme is assessed on aesthetic grounds, these programmes were written to produce results, and correct ones at that. This proved to be an employment advantage.