Compiler-gruppen: Teknisk perfektionisme kontra nytte - 1
Hvordan kunne det gå til at Regnecentralen med sine opfindsomme medarbejdere og elegante tekniske løsninger aldrig blev en rigtig succes? Det har jeg tænkt meget over i de forløbne år, og jeg vil i denne serie af 5 gæsteblogindlæg fortælle hvordan det ser ud i mit eget bakspejl.
Min første tid på RC
I 1960 blev jeg student og begyndte på matematik-fysik studiet ved Københavns Universitet. På Matematisk Instituts bibliotek studerede jeg alt jeg kunne finde om computere. Det mest fantastiske var en lærebog i kodning for DASK (Chr. Andersen, 1958) med en benhård forklaring af maskinkoden. Jeg studerede den intenst og skrev med blyant et par trivielle programmer uden at forestille mig at det nogensinde kunne blive alvor.
På universitetet mødte jeg året efter Bjarner Svejgaard som fortalte om den nye elektronhjerne, GIER. Kort efter troppede jeg op på RC og spurgte om jeg kunne få lærebogen i kodning for GIER, og det kunne jeg. Den var endnu mere spændende at studere, og jeg kunne hurtigt alle ordrerne udenad, selvom de godt nok var meget mere indviklede. Med den ballast søgte jeg et timelønnet job som koder i Finn Larsens gruppe og startede 9. juli 1962 i en alder af 19 år.
Den sommer lærte jeg at finde rundt mellem villaerne på Gl. Carlsberg Vej og Bjerregårds Vej. Der var snedige huller i plankeværkerne og en have som man helst ikke skulle skrå igennem fordi damen der boede der blev vred. Den dag jeg startede blev jeg præsenteret for Bech ved sådan et plankeværkshul. Han bød mig velkommen og sagde at jeg nok skulle blive til noget stort, hvilket undrede mig, for hvor pokker kunne han vide det fra?
Finn Larsen fortalte at assembler-kode var for besværligt, Algol var meget lettere. Så jeg fik udleveret Algol 60 manualen og gik straks i gang med at læse og skrive noget der skulle være et program. Så skulle jeg lære at hulle det på flexowriteren. Det var næsten værre end at skrive det med blyant. Og endelig tog Finn mig ved hånden og kørte det på DASK. Der kom en masse fejludskrifter som jeg ikke forstod meget af, især når jeg nu havde gjort mig sådan en umage.
Finn kiggede i mit program og forklarede hvad der var galt. Han tilføjede at det da var et underligt program med alle de labels og switches (en switch var en slags case-statement der vælger mellem en række labels i programmet). Sådan skrev man ikke et program. Det viste sig at jeg havde læst Algol 60 manualen forfra og prøvet at bruge sprogets dele efterhånden som de blev forklaret. Og bortset fra en masse indledende snak, jeg ikke forstod, og en masse om beregningsudtryk, som var ret trivielt, så startede bogen med labels og switches. Først flere år senere udbredte Dijsktra det glade budskab om at labels og goto var fandens opfindelse.
Jeg tror ikke der gik mere end en uge førend jeg fik min første rigtige opgave. Piet Hein havde i 1945 opfundet et spil, og han vidste ikke hvordan man skulle spille det for at vinde. Det måtte være noget som en elektronhjerne kunne finde ud af, så han henvendte sig til RC. Hvem havde ikke noget at lave? Jo, ham den nye, dvs. mig.
Spillet var en to-dimensional udgave af det klassiske NIM spil. De to spillere skiftes til at tage et antal nabo-brikker, og den der tager den sidste brik har tabt. I det klassiske NIM spil lå brikkerne (som regel tændstikker) i flere rækker, og man måtte tage så mange brikker man ville fra én enkelt række. I Piet Heins udgave lå brikkerne på linier der krydsede hinanden, og man måtte tage så mange brikker man ville fra én enkelt linie. Hver enkelt brik indgik i flere linier.
Hvordan skulle man finde det rigtige træk i en given situation? I princippet kunne man lade computeren prøve alle træk, og for hvert af dem prøve alle træk igen, osv. for at finde vejen til gevinst. Selv om der kun var 12 brikker i Piet Heins spil, ville der være uoverkommeligt mange muligheder - selv for en computer. Jeg grublede flere dage over problemet, og på en tur med Storebæltsfærgen, gik løsningen op for mig.
Jeg beviste først matematisk at man for alle NIM-agtige spil kunne dele spillets situationer i vinder- og tabersituationer. Computeren kunne starte bagfra med de slutsituationer hvor spiller A klart ville vinde fordi der kun var én brik igen til spiller B. Det var vindersituationer. Så kunne computeren regne baglæns og finde de situationer hvorfra man med ét træk kunne komme til en vindersituation. De situationer måtte være tabersituationer. Situationer hvor man kun kunne komme til tabersituationer måtte være vindersituationer.
Da Piet Heins spil kun havde 12 brikker, var der kun 4096 mulige situationer. Ved at udnytte at brikkerne lå i et tre-symmetrisk mønster, kunne man reducere antallet af vindersituationer til noget der let kunne være i lageret, der var på 1024 ord (ca. 5 k bytes). Resten var programmering. (I dag ville jeg have lagret alle de 4096 situationer som 4096 bit, fx i 128 ord).
I dag er denne opgave triviel for dem der beskæftiger sig med spilteori, men det var den ikke den gang. Og jeg var helt alene om at finde løsningen.
Programmet blev lavet i assembler til GIER, og det var det første rigtige program jeg lavede. Jeg husker stadig det umådelige chok da maskinen accepterede programmet og startede det, hvorefter der skete absolut ingenting. Det tog lang tid at vænne sig til at ens tanker kan være rigtige i princippet, men de er altid forkerte i detaljen - i hvert fald i de første mange forsøg. Og computeren forstår overhovedet ikke principper, men kun detaljer.
Piet Hein og RC blev enige om at vise spillet på en udstilling hvor de besøgende kunne spille mod computeren. Vi lavede et bræt med lysende knapper svarende til brikkerne. Desuden var der to knapper med teksterne Svar og Nyt spil. Spilleren lavede et træk ved at trykke på de knapper han ville tage. Maskinen lod dem blinke indtil spilleren trykkede på Svar.
Maskinen slukkede så knapperne og ventede et passende stykke tid som om den tænkte (Piet Hein havde lagt meget vægt på at det skulle se sådan ud). Så blinkede den med de knapper den ville tage og slukkede dem. Hardware-mæssigt havde det været svært, for input/output var computernes svage led. Faktisk var det her projektet gik langsomt. Vi endte med at løse problemet ved at koble knapperne direkte på computerens M-register (multiplikator-registret).
Mit program anbragte så ettaller der hvor knapperne skulle være tændt, og aflæste ændringer i M-registret svarende til de knapper som spilleren trykkede på. Og så skulle jeg selvfølgelig undgå multiplikationer i programmet.
Samarbejdet med Piet Hein strakte sig over det meste af et år, hvor vi også mødtes privat nogle gange. Han var et fascinerende menneske, og han så en mission i at give mig en balanceret forståelse af verden. Det var ikke teknik alt sammen, men en balance mellem kultur og teknik. Den unge mand på 20 år trængte i høj grad til den forståelse, men forstod det kun delvis.
Da RC begyndte at snakke om betaling for arbejdet, blev der problemer. Piet Hein mente at en kulturel indsats som hans, skulle han ikke betale for. Snarere omvendt. Det var heldigvis ikke mit bord, og jeg ved ikke hvordan det endte.
Mine andre opgaver i disse første år var at lave røntgen-krystallografiske beregninger, optimering af sukkerroe transport i Polen, løsning af astronomiens 3-legeme-problem, optimering af sporvejsdrift, og sågar et enkelt program til ATP. Det var alt sammen noget med at prøve sig frem. Der var ingen gode metoder eller retningslinier, og man udvekslede kun i meget begrænset omfang erfaringer. Til gengæld var det også nogle rodede programmer jeg leverede, selvom de fungerede korrekt.
1 af 5. Trykt i Dansk Datahistorisk Forenings festskrift, 2005: Regnecentralen - dansk institut for matematikmaskiner. Gengivet med tilladelse af redaktørerne Henning Isaksson og Ole Pedersen.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.