Preprocessor for desisjonstabeller x)

Like dokumenter
TDT4110 Informasjonsteknologi grunnkurs: Tema: Betingelser og logiske uttrykk Utgave 3: Kap. 3

Læringsmål og pensum. if (be): else (not_to_be):

if (be): else (not_to_be): TDT4110 Informasjonsteknologi grunnkurs: Tema: Betingelser og logiske uttrykk Utgave 3: Kap.

Databank for DATSY/NATBLES/TSP. Brukerveiledning. Ola Jacobsen - INNHOLD

Oversikt. Introduksjon Kildekode Kompilering Hello world Hello world med argumenter. 1 C programmering. 2 Funksjoner. 3 Datatyper. 4 Pekere og arrays

TDT4110 Informasjonsteknologi grunnkurs: Tema: Betingelser og logiske uttrykk. - 3rd edition: Kapittel 3. Professor Alf Inge Wang

U$ERID. woo.0. war CLIST SSB/FRSKAJ/EGAKAT, LISTODT/ALL/ en svarer med ønsket filename USER. trykk på RETURN-knappen

Innholdsfortegnelse. 1. Testing Feiltesting av koden Funksjonstesting: Kilder.10

Plenumsregning 1. Kapittel 1. Roger Antonsen januar Velkommen til plenumsregning for MAT1030. Repetisjon: Algoritmer og pseudokode

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

TDT4110 Informasjonsteknologi grunnkurs: Kapittel 7 Filer og unntak ( exceptions ) Professor Alf Inge Wang Stipendiat Lars Bungum

Notat 2, ST januar 2005

Python: Valg og betingelser. TDT4110 IT Grunnkurs Professor Guttorm Sindre

Læringsmål og pensum. Oversikt

Skanning del I. Kapittel 2 INF 3110/ INF

Scanning - I Kap. 2. Hva scanneren gjør

Betinget eksekvering og logiske tester i shell

MAT1030 Diskret Matematikk

Programmering Høst 2017

UNIVERSITETET I OSLO

Typisk: Kan det være både nøkkelord og navn, så skal det ansees som nøkkelord

Kap.4 del I Top Down Parsering INF5110 v2005. Arne Maus Ifi, UiO

Typisk: Kan det være både nøkkelord og navn, så skal det ansees som nøkkelord

Skanning del I INF /01/15 1

BEREGNING AV FORSKUDDSTREKK INNTEKTSÅRET Desember Skatteetatens IT- og Servicepartner

Programmering i R. 6. mars 2004

Velkommen til plenumsregning for MAT1030. MAT1030 Diskret matematikk. Repetisjon: Algoritmer og pseudokode. Eksempel fra boka. Eksempel

Orientering for bruk av SSB sr.egresjonsprogram. 45 variable, dobbel presisjon. a v

Semantisk Analyse del III

IN1010 V18, Obligatorisk oppgave 5

TDT4110 IT Grunnkurs Høst 2014

7034 Trondheim - NTH 1.1 KILDEPROGRAM S KOMPILERING OG ASSEBMLERING S LENKING AV OBJEKTFILER S UTFØRELSE AV PROGRAMMET S.

GJØVIK INGENIØRHØGSKOLE

Oppsummering fra sist

<?php. count tar en array som argument, og returnerer et tall som uttrykker antallet innførsler i arrayen.

MAT1030 Diskret matematikk

Utførelse av programmer, funksjoner og synlighet av variabler (Matl.)

Utførelse av programmer, metoder og synlighet av variabler i JSP

Oppgaver til kodegenerering etc. INF-5110, 12. mai, 2015

Oblig2 - obligatorisk oppgave nr. 2 (av 4) i INF1000 h2006

INF3430/4431. VHDL byggeblokker og testbenker

MAT1030 Plenumsregning 1

Hjemmeeksamen 2 i INF3110/4110

NOARK EGENERKLÆRING OM SYSTEMFUNKSJONALITET FRA PRODUSENTER AV NOARK-SYSTEMER

Kodegenerering, del 2: Resten av Kap. 8 pluss tilleggsnotat (fra kap. 9 i ASU ) INF5110 V2007

Obligatorisk oppgave 1 INF1020 h2005

Kap. 4: Ovenfra-ned (top-down) parsering

Datatyper og typesjekking

Python: Variable og beregninger, input og utskrift. TDT4110 IT Grunnkurs Professor Guttorm Sindre

Datatyper og typesjekking

Oblig2 - obligatorisk oppgave nr. 2 (av 4) i INF1000 v2008

TDT4110 Informasjonsteknologi, grunnkurs Uke 35 Introduksjon til programmering i Python

Matematikk Øvingsoppgaver i numerikk leksjon 2 Løsningsforslag

Plenumsregning 1. MAT1030 Diskret Matematikk. Repetisjon: Algoritmer og pseudokode. Velkommen til plenumsregning for MAT1030

Andre sett obligatoriske oppgaver i INF3100 V2013

Oppgaver til kodegenerering etc. INF-5110, 16. mai, 2014

Løse reelle problemer

Desisjonstabeller og generering av maskinprogrammer for granskning av statistisk primaermateriale'

Dark Stakkmaskin. Aritmetiske instruksjoner

Matematikk Øvingsoppgaver i numerikk leksjon 2 Løsningsforslag

Datatyper og typesjekking

Makrosystemet. DATSY-notat nr. 1. David Walker

HØGSKOLEN I SØR-TRØNDELAG Avdeling for informatikk og e-læring - AITeL

Mål. Pensum. TDT4110 Informasjonsteknologi grunnkurs: Tema: Filer og unntak (exceptions) Utgave 3: Kap. 6. Terje Rydland - IDI/NTNU

Tabell l. Felles kjørenummer for studenter ved Universitetet i Trondheim

INF oktober Dagens tema: Uavgjørbarhet. Neste uke: NP-kompletthet

Øvingsforelesning 1 Python (TDT4110)

Oblig2 - obligatorisk oppgave nr. 2 (av 4) i INF1000 v2009

Oblig2 - obligatorisk oppgave nr. 2 (av 4) i INF1000

Dark load-store-maskin

TDT4110 IT Grunnkurs Høst 2015

PRESENTASJON OG DROFTING AV ET FORSLAG OM MAKRODIREKTIVER. DATSY-notat nr. 3. David Walker INNHOLD

Dataøvelse 3 Histogram og normalplott

Kort om meg. INF1000 Uke 2. Oversikt. Repetisjon - Introduksjon

IB 69/1 Oslo, 7, januar 1969 REGISTRERT OG OPPGITT FLYTTEDATO. En undersøkelse av norske flyttedata for Eivind Gilje, Jan Mo Moen og Helge Skaug

Brother original fargekassett Testmetode for å fastslå oppgitt sideytelse basert på ISO/IEC24711-standarden

Løkker og arrayer. Løse problemer med programmering. INF1000, uke3 Geir Kjetil Sandve

Dagens temaer. Kort repetisjon. Mer om cache (1) Mer om cache (2) Read hit. Read miss. Write hit. Hurtig minne. Cache

SIE 4005, 9/10 (4. Forelesn.)

Informasjon Prøveeksamen i IN1000 høsten 2018

INF5110, onsdag 19. februar, Dagens tema: Parsering ovenfra-ned (top-down)

Oppgave 1 Hva tror du følgende program skriver ut til terminalen? Diskuter med gruppen.

Obligatorisk oppgave 4 i INF1010, våren 2014: "Leger og resepter" Versjon 1.1

Kom forberedt til tirsdag. INF1000 Tips til obligatorisk oppgave 4. Noen generelle tips. Oblig4: Komme igang

Brukerveiledning for ArkN4

løsningsforslag-uke5.txt

MER OM ARRAYER. INF1000: Forelesning 4. Anta at vi ønsker å lagre en liste med navnene på alle INF1000-studentene:

LOGISK PROGRAMMERING. Prolog (kapittel 8): Fakta Regler Spørsmål Variable Hvordan finne svar? Unifikasjon Lister

Kap. 4 del I Top Down Parsering INF5110 v2006. Stein Krogdahl Ifi, UiO

IN1000 Obligatorisk innlevering 7

INF1000: Forelesning 4. Mer om arrayer Metoder

Notat 2, ST Sammensatte uttrykk. 27. januar 2006

Dagens temaer. Fra kapittel 4 i Computer Organisation and Architecture. Kort om hurtigminne (RAM) Organisering av CPU: von Neuman-modellen

Leksjon 3. Kontrollstrukturer

Når en bruker skriver sitt navn ("Ole") i et form-element med name="fornavn" som attributt. klikker på submit-knappen

Datatyper og typesjekking

LITT OM OPPLEGGET. INF1000 EKSTRATILBUD Stoff fra uke September 2012 Siri Moe Jensen EKSEMPLER

Øvingsforelesning TDT4105 Matlab

Kapittel 5 - Advanced Hypertext Model Kapittel 6 - Overview of the WebML Development Process

Steg 1: Lag en figur som bytter drakt

Transkript:

IB 65/3 Oslo, 26. mars 1965 Preprocessor for desisjonstabeller x) av Thor Aastorp Innhol d 1. Generell beskrivelse 2. Regler og begrensninger 3. Kontrollkortene 3.1 Problemkort 3.2 Tabellkort 3.3 Spesifikasjonskort 3.3.1 Egne Fortran-statements og -rutiner 3.3.2 Testrelasjoner og desisjonsbetingelser 3.3.3 Aksjoner og aksjonsselektorer 3.4 Variable format-kort 4. Logical unit numbers x) Eksempler pa bruk av desisjonstabeller for spesifisering av revisjonskriterier er gitt i ANO IB 65/2: The Efficiency of Automatic Detection and Correction of Errors in Individual Observations as Compared with Other Means for Improving the Quality of Statistics, by Svein Nordbotten. Bette notat er et internt arbeidsdokument og and ikke offentliggjøres eller sendes andre etater, institusjoner e. 1., verken i sin helhet eller i utdrag.

Generell beskrivelse PreProcessoren er skrevet i Fortran for CDC 3 600. På grunnlag av kontrollkort som spesifiserer desisjonstabellen vil preprocessoren generere folgende program og rutiner (alle i Fortran): a) Et hoved- eller rammeprogram som ved kjøring først sorger for g lese inn kontrollkort inneholdende formatspesifikasjon av input-data. PA grunnlag av dette format blir de enkelte input-records lest inn. Etter at en inputrecord er lest inn, vil hovedprogrammet påkalle subrutine for de enkelte desisjonstabellene. Subrutinen for desisjonstabel1 nr. 1 blir påkalt og utført først, deretter blir de andre subrutinene påkalt i tabellnummer rekkefølge. Denne rekkefølgen er imidlertid ikke absolutt, men kan endres ved spesifikasjon. b) En fast subrutine som påkalles av subrutinene for de enkelte desisjons tabellene etter at de spesifiserte relasjoner er testet. Resultatet av disse testene blir i subrutinen sammenliknet med de spesifiserte desisjonsregier for A finne den første regel som blir tilfredsstilt. c) Der genereres en subrutine for hver desisjonstabell. En slik subrutine vil bestå av eventuelle egne Fortran-statements og -rutiner, testing av de spesifiserte relasjoner og rutiner med de oppgitte aksjoner. 2. Regler og begrensninger Brukeren av denne preprocessor mg være oppmersom på de begrensninger som gjelder og de regler man må folge ved spesifiseringen av sine desisjons - tabeller. Nedenfor er listet de viktigste punktene; konvensjonene for utfylling av kontrollkortene vil bli gjennomgått i detalj i neste kapitel. a) Man kan spesifisere inntil 10 tabeller. b) Innen hver desisjonstabell kan man ha inntil 94 testrelasjoner,32 desisjonsregler og 99 aksjoner. 0) Man kan bruke inntil 999 spesifikasjonskort for hver tabell. d) Det er full anledning til (i visse tilfelle endog påkrevd) å spesifisere egne Fortran-statements og -rutiner. e) Antall variable format -kort (som angir formatet på input-data) kan være inntil 5 kort. f) Man kan lese inn maksimalt 99 variable (felter) for hver input-record. Variable blir lest inn i en real array Y med dimensjonen 100.,Dette betyr at alle variable Mg leses inn etter F -format og at all referanse blir Y (1), y (2), osv.

Kontrollkortene 3.1 Problemkort Som forste kontrollkort må man ha et såkalt problemkort med disse opplysningene: Kol. 1-2: PR (for 2rpb1emkort) 3-10: Problemnavn (samme regel som for Fortran program navn) 11-12: Antall desisjonstabeller, t (t 10) 13-14: Antall variable innen hver record, Y (T< 100) 15-16t Antall variable format-kort, k (k 5). 3.2 Tabellkort Foran spesifikasjonskortene for en desisjonstabell må man ha et tabellkort med disse opplysningene: Kol. 1-3: TAB (for tabellkort) I,4-5: Tabellnummer, n (n 10) - 82 Antall spesifikasjonskort for tabellen, m (m 000)- Tabellkortet er ikke medregnet i dette antallet. - 10: Antall testrelasjoner, r.4-94) 11-12: Antall aksjoner, a (a 99). 3.3 Spesifikasjonskort Spesifikasjonskortene innen en desisjonstabell kan deles inn i tre grupper: i) Egne Fortran-statement og -rutiner i) Testrelasjoner og desisjonsbetingelser iii) Aksjoner og aksjonsselektorer. Spesifikasjonskortene har følgende format: Kol. 1-5: Statement-nr. t' 6 : Continuation code 7 48: Statement 49-80: Desisjonsbetingelser eller aksjonsselektorer. Under spesifikasjonen må man ware oppmerksom på og ta hensyn til følgende: i) Feltene fra input-records blir lest inn i en real array Y. av dimensjonen 100. Referanse til en variabel innen inputrecorden. blir da Y (i) hvor i angir feltets plass innen recorden, Eksempel: Y (2), Y (6), osv. Arrayen Y inngår i en common-blokk som er felles for hovedprogrammet og subrutinene.

spesifikasjonene bør man unngå å benevne common-blokker med navn som begynner med LLL. Videre bor man unngå g spesifisere egne variable med navn som TAB, Y N1, N2, N3 osv og navn som begynner med LLL eller LIST. in) Man kan ikke operere med statement-numrene 99 900 99 999. 3.3.1 Egne Fortran-statements og -rutiner De eneste tilfellene hvor det kreves spesifikasjoner i denne gruppen, er når man i en eller flere relasjoner har referert til lister (kodelister Disse listene som skal ha et navn begynnende med LIST, må defineres og spesifiseres ved hjelp av Fortran-statement. Listen mg ware lagret som en éndimensjonal array, dvs. at man må oppgi størrelsen på listen i et dimensjonstatement, f.eks. "Dimension LISTA (140)". Videre må man definere en integer variable Ni, hvor i er et nummer som angir i hvilken rekkefolge de enkelte listene blir referert til i relasjonene. Hvis LISTA er den andre listen som det blir referert til i relasjonene, må man definere N2 ved "Data (N2=140)" eller "N2=140". Det må derfor være like mange Ni som det er relasjoner med LIST i. På tilsvarende måte må man definere de enkelte elementene i listen, enten ved data-statements eller ved aritmetiske replacement-statements. Hvis den samme listen blir referert til i flere relasjoner i samme tabell, ma man definere like mange Nils, Eks.: LISTA blir referert til både som den andre og fjerde listen, en må da sette "N2=140" og "N4=140" (eventuelt "N4=N2 140"). denne gruppen av spesifikasjonskort kan man spesifisere beregninger av ulike slag, innlesing av kontrolldata osv. Hvis man innfører variable som skal være felles for flere desisjonstabeller, må disse spesifiseres i commonblokker. Man må da være oppmerksom på at det bare er elementer i såkalte "labelled common" som kan defineres i data-statements. Under skriving av statements i denne gruppen kan kel. 49-80 ikke brukes. Det betyr at man arbeider med et forkortet Fortran-kortformat. Continuation kan brukes på vanlig måte. 3.3.2 Testrelasjoner og desisjonsbetingelser Under spesifiseringen i denne gruppen nyttes folgende format: Kol. i- 5: Statement nr. tt 6 Continuation it tt 7-48: Relasjoner 49-80: Desisjonsbetingelser. De relasjonene som man av en eller annen grunn ønsker å referere til, enten i egne Fortran-statements eller i aksjonsdelen, mg ha statement nr.. Continuationkort kan man bruke på vanlig måte.

En enkel relasjon skriver man slik: P op Q, hvor p og Q e r arjt - metiske uttrykk og "op" er en av disse relasjonskodene:.eq. som betyr Lik (=).NE. Forskjellig.GT. Storre enn Større eller lik.lt. Mindre enn (<) Mindre eller lik Resultatet av en test av en relasjon kan bli enten 'yes" eller 'no" avhengig av hvorvidt forholdet mellom de to aritmetiske uttrykkene tilfreds stiller den betingelse som relasjonskoden angir. Eksempel: Testresultatet av relasjonen "Y(2).GT.100." blir "yes" når verdien av Y(2) er storre enn 100. Er verdien av Y(2) lik eller mindre enn 100, blir resultatet "no". En testrelasjon kan bestå av flere enkle relasjoner. Relasjonene bindes da sammen.med de logiske operasjonskodene:.and.,or. Har man de to enkle relasjonene R1 og R2, kan man ha: ) Rl.AND.R2; testresultatet av denne sammensatte relasjonen blir "yes" bare når resultatene av både R1 og R2 er 'yes". R1.0r.R2; her blir testresultatet "yes" når resultatet av RI og/eller R2 er "yes' Man kan også spesifisere testrelasjoner som består av flere enkle relasjoner, uten å binde dem sammen med AND eller OR Hver enkelt relasjon må da begynne på ny linje og etterfolge hverandre. Preprocessor vil behandle disse relasjonene på OR -basis. I en relasjon er det anledning til å referere til hele lister (kodelister o.1.). Disse listene må da defineres i egne Fortran-statements (punkt 3.3.1) En slik liste mg ha et navn som begynner på LIST og i relasjonen må dette navnet med subscript I stå først, Eks.: LIST Nr i LII.EQ.Y(1) (Det som er understreket er obligatorisk i en slik relasjon). Man kan ikke referere til flere lister i en og samme testrelasjon. I den første linjen innen hver testrelasjon spesifiserer man desisjonsbetingelsene (kol. 49-80). Man bruker her bare Y (for yes) N (for No.) eller blank. For hver desisjonstabell kan man maksimalt ha 94 testrelasjoner og 32 desisjonsregler.

6 3.3.3 Aksjoner og aksjonsselektorer Man kan ha inntil 99 aksjoner innen hver desisjonstabell. Hver aksjon spesifiseres ved hjelp av Fortran-statements. I det forste kortet i en aksjon angir man dessuten aksjonsselektorene i kol. 49-80. Første statement i en aksjon kan ikke være format-statement. Videre kan ikke en aksjon avsluttes med IF-statement (med unntak av logiske IF-statements med 6n. utgang). Som nevnt tidligere vil subrutinene for de enkelte desisjonstabellene normalt bli påkalt og utfort i nummerrekkefølge. Man har imidlertid anledning til A endre denne rekkefølgen ved spesifikasjon. Hvis man i aksjonsdelen i en desisjonstabell har et statement av typen "TAB.W, vil hovedprogrammet etter at aksjonen med dette statement er utført, påkalle subrutinen for desisjonstabell Nr. M. Dette er under forutsetning av at desisjonstabell Nr. M forekommer, hvis ikke blir neste input-record innlest og subrutinen for tabell nr. 1 påkalt. Eksempel: I desisjonstabell nr. 3 inneholder en aksjon dette statement: "TAB=6". Når denne aksjonen er fullført, blir desisjonstabell nr. 6 påkalt istedenfor tabell nr. 4. En kan imidlertid ikke nytte TAB=m tabell m. 3.4 Variable format-kort Dette eller disse kontrollkortene leses av rammeprogrammet mens de kontrollkortene som er nevnt foran, leses av preprocessoren. Man må ha med så mange format-kort som angitt på problemkortet. Alle 80 kolonnene i kortet kan brukes. Vær oppmerksom på at alle variable må leses inn ved F-format. 4. Logical unit numbers a) Logical unit 1: Herfra leses kontrollkortene b) It it 2: Feilutskrifter c) It It 3: Liste over desisjonstabellene d) tt tt 4: På denne LU som må være magnetbånd genereres rammeprogram med subrutiner e) tt It 5: Mellomlagringsbånd, kan ikke være scratch f) It tt 6: Input-data.