[Musik spiller] David J. MALAN: Okay. Dette er CS50, og dette er starten på uge to. Så lad os begynde i dag med en fejl. En fejl, selvfølgelig, er en fejl i et program, og du får meget bekendt med dette koncept hvis du aldrig har programmeret før. pset0 og nu pset1. Men lad os betragte noget lidt simpelt i starten. Dette program her, at jeg kastede sammen i forvejen, og jeg hævder, at dette burde udskrive 10 stjerner på skærmen ved hjælp af printf, men det er åbenbart fejlbehæftet eller anden måde. 

Eftersom specifikation, Det burde udskrive 10 stjerner, men det gør tilsyneladende ikke, hvad ville du hævder er fejlen? Ja? Så det er en off ved en fejl, og hvad mener du med det? OK. Fremragende. Så vi har angivet en starter på nul for jeg, og vi har angivet en n-værdi på 10, men vi har brugt mindre end eller lig med. Og grunden til, at dette er to tegn og ikke bare én symbol, ligesom i en matematik bog, er, at du ikke har en måde at udtrykke et tegn tilsvarende. 

Så det betyder mindre end, men hvis du begynder at tælle på nul, men du tælle hele vejen op gennem og er lig med 10, du er selvfølgelig at gå til tælle 11 ting i alt. Og så du kommer til at udskrive 11 stjerner. Så hvad kunne være en rettelse til dette? Ja? 

Så bare justere mindre end eller lig med bare være mindre end og der er, jeg hævder, måske en anden løsning, også. Hvad kan du ellers gøre? Ja? 

Så begynder svarende det til 1, og forlade mindre end eller lig med. Og helt ærligt, jeg vil hævde at for et typisk menneske, dette er sandsynligvis mere ligetil. Begynde at tælle på 1 og tælle op til 10. Væsentlige gøre, hvad du mener. 

Men virkeligheden er i programmering, som vi har set, dataloger og programmører generelt begynde at tælle på nul. Og så det er fint, når du vænne sig til det. Din tilstand vil generelt være noget lignende mindre end. Så simpelthen en logisk fejl, at vi kunne nu fix og i sidste ende genoversætte dette, og få bare 10. 

Jamen hvad med denne fejl her? Her igen, jeg hævder, at jeg har et mål om at udskrive 10 stars-- én pr linje denne gang, men det gør ikke. Før vi foreslå hvad rettelsen er, hvad betyder dette udskrive visuelt hvis jeg skulle kompilere og kør dette program tror du? Ja? 

Star. Så alle stjernerne på samme linje er, hvad jeg har hørt, og derefter den nye linje tegn. Så lad os prøve det. Så gør buggy-1, indtaste, og jeg ser klang kommandoen som vi talte om sidste gang. ./buggy-1, og faktisk ser jeg alle 10 stjerner på samme linje, selvom jeg hævde i min specifikation bare en kommentar oven den kode, som jeg har til formål at gøre én pr linje. Men det ser rigtigt. 

Nu linie 15 ser det ud som om jeg er udskrivning af en stjerne, og derefter linie 16 det ser ud som om jeg er udskrivning en ny linje, og de er begge indrykket så Jeg inde i sløjfen tydeligt. Så skulle jeg ikke gøre stjerne, nye linje, stjerne, ny linje, stjerne, ny linje? Ja? 

Ja, i modsætning til et sprog som Python, hvis du er fortrolig, indrykning ikke noget til computeren. Det kun betyder noget for mennesket. Så mens jeg her har opfundet linjer 15 og 16-- der ser smuk, men computeren er ligeglad. Computeren bekymrer sig om faktisk at have krøllede parenteser omkring disse linjer kode. 

Så det er clear-- ligesom i Scratch-- at disse to linjer kode skal fuldbyrdes. Som en af ​​de gule Scratch puslespil stykker igen og igen og igen. 

Så nu, hvis jeg igen køre dette program-- ./buggy-2-- Hm. Jeg har en fejl nu. Hvad har jeg glemt at gøre? Ja, så jeg ikke kompilere det. Så gør buggy-2. Ingen sådan fil fordi jeg ikke faktisk kompilere den anden version. Så nu interessant sort variable-- ikke 2. Vi laver 1. Gør buggy-1-- ./buggy-1-- og nu hver af dem er på samme linje. 

Nu er der en undtagelse til denne formodede fordring af mine at du har brug for disse krøllede parenteser. Hvornår er det faktisk OK-- hvis du har bemærket i afsnit eller textbooks-- at udelade de krøllede parenteser? Ja? 

Præcis. Når der kun er én linje kode, som du ønsker at blive forbundet med sløjfe som i vores første eksempel. Det er helt legitimt at udelade de krøllede parenteser blot som en slags bekvemmelighed fra compiler til dig. Ja? Godt spørgsmål. Ville det blive betragtet som en stil fejl? Vi ville promote-- som i CS50 Vejledning, webadressen for hvilke er pset1-- der altid anvende de krøllede parenteser. Bestemt, hvis du er ny til programmering. Virkeligheden er, at vi ikke er kommer til at forbyde dig fra at gøre disse bekvemmeligheder. Men hvis du bare får ind i swing ting, absolut bare altid bruge den krøllede seler, indtil du får hænge af det. Godt spørgsmål. 

Okay. Så det da var en fejl. I hvert fald i noget forholdsvis enkel. Og alligevel tror du måske dette er temmelig rudimentær, right? Dette er sortering af den første uge se på sproget ligesom, se jeres fejl deri. Men virkeligheden er disse faktisk repræsentativ af nogle temmelig skræmmende problemer som kan opstå i den virkelige verden. 

Så nogle af jer måske husker hvis du følger tech nyheder, eller måske endda fanget vind af dette i februar af det sidste år, at Apple havde gjort lidt af en fejl i begge iOS, operativsystemet på deres telefoner, og også Mac OS operativsystemet på deres stationære og bærbare computere. Og du så sådanne overskrifter som dette. Og derefter, Apple lovede at fastsætte denne fejl, og meget hurtigt gjorde ordne det i iOS, men så i sidste ende fastsættes det i Mac OS samt. 

Nu er ingen af ​​disse overskrifter alene virkelig afsløre, hvad det underliggende problem var, men fejlen i sidste ende blev reduceret til en fejl i SSL, Secure Sockets Layer. Og lang historie kort, dette er den software at vores browsere og andre software, der bruges til at gøre hvad? 

Hvis jeg sagde, at SSL er involveret, når du besøge en webadresse, der begynder med https, hvad så måske SSL være relateret til? Kryptering. Så vi vil tale om dette i de kommende dage. Kryptering, kunsten scrambling oplysninger. 

Men lang historie kort, Apple engang siden havde begået en fejl i deres gennemførelse af SSL, den software, der i sidste ende gennemfører URL'er som HTTPS eller max forbindelser der også. Resultatet af det er, at din forbindelser kunne potentielt opfanges. Og dine forbindelser var ikke nødvendigvis krypteret hvis du havde nogle dårlige fyr i mellem dig og destinationen hjemmesiden, der vidste hvordan man kan drage fordel af dette. 

Nu Apple i sidste ende sendt en rettelse til dette endelig og beskrivelsen deres løsning var dette. Sikker transport undladt at validere ægtheden af ​​forbindelsen. Spørgsmålet blev behandlet af genoprette manglende validering trin. 

Så dette er en meget hånd bølget forklaring for blot at sige, at vi skruet op. Der er bogstaveligt talt en linje kode, der var fejlbehæftet i deres gennemførelse af SSL, og hvis du går online og søge efter dette du kan faktisk finde den originale kildekode. For eksempel er et skærmbillede af kun en del af en temmelig stor fil, men dette er en funktion tilsyneladende kaldet SSL verificere tegn server nøgleudveksling. Og det tager en flok argumenter og indgange. Og vi kommer ikke til at fokusere for meget på minutiaernes der, men hvis du fokuserer på kode inde af det øverste function-- lad os zoome ind på det. Du har måske allerede mistanke hvad fejlen måske være, selvom du ikke har nogen idé i sidste ende, hvad du kigger på. Der er lidt af en anomali her, hvilket er hvad? 

Ja, jeg kan ikke rigtig lide udseendet af to Goto mislykkes. Helt ærligt, jeg ved ikke rigtig, hvad goto ikke midler, men med to af dem ryg mod ryg. Det er bare sådan gnider mig intellektuelt den forkerte vej, og faktisk hvis vi zoomer ind på bare disse linjer, dette er C. 

Så en masse af Apples kode selv er skrevet i C, og denne tilsyneladende er virkelig equivalent-- ikke til den smukke indrykning version, men hvis du erkende, at der er ingen krøllede parenteser, hvad Apple skrev virkelig var kode, der ser som denne. Så jeg har zoomet ud, og jeg bare fast indrykningen i den forstand, at hvis der er nogen krøllede parenteser, at sekund goto mislykkes, der er i gult kommer til at udføre uanset hvad. Det er ikke forbundet med den hvis betingelse ovenover. 

Så selv igen, hvis du ikke helt forstå, hvad det eventuelt kunne være at gøre, ved, at hver af disse conditions-- hver af disse linjer er et meget vigtigt skridt i processen med at tjekke Hvis dine data er i virkeligheden krypteret. Så springer en af ​​disse trin, ikke den bedste idé. 

Men fordi vi har denne anden goto mislykkes i gul, og fordi når vi slags æstetisk flytte den til venstre, hvor det logisk er i øjeblikket, hvad betyder det for den linje kode under den anden goto mislykkes skulle man tro? Det er altid vil blive sprunget over. Så gotos er generelt ildeset grunde vil vi ikke rigtig gå ind i, og faktisk i CS50 vi tendens til ikke at undervise i denne redegørelse goto, men du kan tænke på goto mislykkes således gå hoppe til en anden del af koden. 

Med andre ord springe over denne sidste linje helt, og så resultatet af denne dum simpel fejl, der var lige et resultat af nok nogen kopiere og indsætte en alt for mange gange var, at hele sikkerhed af iOS og Mac OS var sårbar over for aflytning af skurkene i temmelig lang tid. Indtil Apple endelig løst dette. 

Nu, hvis nogle af jer er faktisk kører gamle versioner af iOS eller Mac OS, du kan gå til gotofail.com som er en hjemmeside, at nogen sat op i det væsentlige bestemme programmatisk Hvis din computer er stadig sårbar. Og helt ærligt, hvis det er, er det nok en god idé at opdatere din telefon eller din Mac på dette punkt. Men der, bare bevis på, hvor en vurdering af disse lavere niveau detaljer og retfærdigt enkle idéer kan virkelig oversætte til beslutninger og problemer, affected-- i denne case-- millioner af mennesker. 

Nu nogle ord på administration. Afsnit vil starte denne kommende søndag. Du vil modtage en e-mail fra weekend om sektion, på hvilket tidspunkt den resektion proces vil begynde, hvis du har indså du nu har nogle nye konflikter. Så dette sker hvert år, og vi vil rumme i de kommende dage. 

Kontoret hours-- gør holde øje på denne liste her. Ændrer en lille smule i denne uge, især starttidspunktet og placeringen, så du skal konsultere at før overskriften til kontortid nogen af ​​de næste fire nætter. Og nu et par ord om vurdering især da du dykke ned i problemet sætter en og videre. 

Så pr specifikationen, disse er generelt akser, langs hvilke vi evaluerer dit arbejde. Anvendelsesområde refererer til hvad omfang din kode redskaber de funktioner, der kræves vores specifikation. Med andre ord, hvor meget af et stykke sæt gjorde du bide. Har du lavet en tredjedel af det, halvdelen af ​​det, 100% af det. Selv hvis det ikke er korrekt, hvor meget har du forsøger? Så der fanger niveau indsats og beløbet som du lidt væk fra den problem sæt problemer. 

Correctness-- dette ene, at hvilket omfang, er din kode overensstemmelse med vores specifikationer og fri for fejl. Så virker det korrekt? Hvis vi giver det nogle input, gør det give os output, som vi forventer? Design-- nu dette er den første af de særligt kvalitative, eller dem, der kræver menneskelig vurdering. Og ja, det er derfor vi har et personale af så mange pædagogiske stipendiater og kursus assistenter. I hvilket omfang er dit kode skrevet godt? 

Og igen er dette en meget kvalitative vurdering der vil arbejde med dig på bidirektionalt i de kommende uger. Så når du får ikke kun numeriske scoringer, men også en skriftlig scoringer, eller maskinskrevet feedback eller skriftlig feedback på engelske ord. Det er, hvad vi vil bruge til at køre dig mod faktisk skriver bedre kode. Og i foredrag og afsnit, vil vi prøve at pege out-- så ofte som vi can-- hvad der gør et program ikke kun korrekt og funktionelt godt, men også godt designet. Den mest effektive det kunne være, eller selv den smukkeste det kan være. 

Hvilket fører os til stil. Stil i sidste ende er en æstetisk dom. Vidste du vælge godt navne til dine variabler? Har du indrykket din kode korrekt? Ser det godt, og derfor, er det let for et andet menneske til at læse jeres respektive af dens korrekthed. 

Nu generelt pr pensum, score vi disse ting på en fem punkts skala. Og lad mig hammer hjem punkt at et tredimensionalt er faktisk godt. Meget hurtigt gøre folk begynde at gøre aritmetik. Når de får en tre ud af fem om korrekthed for nogle pset og de tror sgu, jeg går til 60% som er i det væsentlige en D eller E. 

Det er ikke den måde, vi tænke på disse numre. En tre er faktisk godt, og hvad vi forventer generelt i begyndelsen af begrebet er, at hvis du får en flok af three's-- måske et par af messer, et par fours-- eller et par toere, et par fours-- det er et godt sted at starte. Og så længe vi ser et opadgående bane over tid, du er i et særligt godt sted. 

Formlen vi bruger til at vægt ting er i det væsentlige dette pr pensum, hvilket betyder blot, at vi lægge større vægt på korrekthed. Fordi det er meget ofte korrekthed der tager mest tid. Tro mig nu. Du vil find-- mindst i en pset-- at man tilbringer 90% af din tid arbejder på 10% af problemet. 

Og alt slags fungerer bortset fra en eller to fejl, og dem er de fejl, der holde dig op sent om natten. De er dem, der slags slippe dig. Men efter at sove på det, eller deltage kontortid eller stille spørgsmål online, når du kommer til at 100% mål, og det er derfor, vi vægt Korrekthed mest. Design en lidt mindre, og style en lidt mindre end det. Men husk på mind-- stil er måske den nemmeste af disse til at bide fra som pr stil vejledning. 

Og nu, en mere alvorlig Bemærk på akademisk ærlighed. CS50 har den uheldige skelnen af er den største producent af Ad Board tilfælde næsten hvert år historisk. Det er ikke fordi de studerende snyde i CS50 noget mere så end nogen anden klasse, men på grund af arten af ​​det arbejde, det faktum, at det er elektronisk, det faktum, at vi ser for det, og det faktum, at vi er dataloger, Jeg kan sige, vi er desværre meget gode til at opdage det. 

Så hvad betyder det reelt? Så det, pr pensum, kurset filosofi virkelig koges ned til at være rimelig. Der er denne linje mellem gøre et arbejde på din egen og få en lille smule af rimelig hjælp fra en ven, og direkte at gøre det arbejde for din ven, eller sende ham eller hende din kode så han eller hun kan simpelthen tage eller låne det ud til højre. Og der krydser linjen at vi trukket i klassen. 

Se, pensum i sidste ende for de strækninger at vi trækker som værende rimelig og urimelig adfærd, men det virkelig kog ned til essensen af dit arbejde behøver at være din egen i sidste ende. Nu med det sagt, der er en heuristisk. Fordi som du måske imagine-- fra kontortid og det visuelle og de videoer vi har vist således far-- CS50 er faktisk beregnet til at være collaborative og så samarbejdsvillig og social som muligt. Som kollaborative som det er stringent. 

Men med dette sagt, heuristisk, som du kan se i pensum, er, at når du har et problem. Du har nogle fejl i din kode, som du ikke kan løse, er det rimeligt for dig at vise din kode til en anden. En ven selv i klassen, en ven sidder ved siden af ​​dig på kontortid, eller et medlem af personalet. Men de kan ikke vise deres kode til dig. 

Med andre ord, en svar på dine question-- Jeg har brug for help-- ikke åh, her er min kode. Tag et kig på dette og udlede det hvad du vil. Nu, selvfølgelig, er der en måde klart til spil dette system, hvor jeg vil vise dig min kode, før de har et spørgsmål. Vis mig mit din kode før de har et spørgsmål. Men se pensum igen til finere detaljer om, hvor denne linje er. 

Netop nu male billedet og dele så gennemsigtigt som muligt hvor vi er i de seneste år, dette er antallet af Ad Board tilfælde at CS50 har haft over de sidste syv år. 14 sager denne seneste fald. Med hensyn til de involverede studerende, det var 20 nogle ulige elever denne sidste efterår. Der var et højdepunkt på 33 studerende nogle år siden. Mange af dem er desværre ikke længere her på campus. 

Students involveret som en procentdel af klasse har historisk varierede fra 0% til 5,3%, hvilket er kun at sige dette er en årlig udfordring. Og hen imod det, hvad vi ønsker at gøre, er at formidle en at vi dd-- bare FYI-- sammenligne på en retfærdighed til de studerende, der er efter linje i overensstemmelse hermed. Vi gør sammenligne alle aktuelle indlæg mod alle tidligere missioner fra de sidste mange år. 

Vi ved også, hvordan man kan google rundt og find kode repositories online, diskussionsfora online, jobsites online. Hvis en studerende kan finde det, kan vi sikkert finder det lige så meget som vi desværre gør. Så hvad du vil se i pensum dog er denne beklagelse klausul. Jeg kan helt sikkert værdsætter, og vi alle har personale have gjort kursus som denne eller dette sig over tid, sikkert ved, hvad det er ligesom når livet kommer i vejen, når du har nogle sent nat deadline-- ikke kun i denne klasse, men another-- når du er helt udmattet, stresset, have en uforholdsmæssig antal af andre ting at gøre. Du vil gøre på et tidspunkt i liv helt sikkert en dårlig, måske sent nat beslutning. 

Så pr pensum, der er denne klausul, således at hvis inden for 72 timer for at gøre nogle dårlig beslutning, du ejer op til det og nå ud til mig og en af ​​kursets hoveder og vi vil have en samtale. Vi vil håndtere tingene internt i håb det bliver mere af en undervisning øjeblik eller liv lektion og ikke noget med særligt drastiske forgreninger som du kan se på disse diagrammer her. 

Så det er en meget alvorlig tone. Lad os stoppe for bare et par stykker sekunder for at bryde spændingen. 

[Musik spiller] 

David J. MALAN: Okay, så hvordan var det for en Overgang? Til dagens primære emner. Den første er abstraktion. En anden, som vil være repræsentation af data, som ærligt talt er en virkelig tør måde at sige, hvordan kan vi gå om at løse problemer og tænkning om at løse problemer? Så du har set i Scratch, og du har set måske allerede i pset1 med C at du ikke kun kan bruge funktioner som printf, at andre mennesker i år tidligere skrev til dig. Du kan også skrive dine egne funktioner. 

Og selvom du måske ikke har gjort dette i C, og helt ærligt i pset1 du ikke virkelig har brug for at skrive din egen funktion fordi problem-- mens måske skræmmende først glance-- du vil se kan i sidste ende løses med ikke alle, at mange linjer kode. Men med det sagt, i form for at skrive din egen funktion, indse, at C giver du denne evne. 

Jeg har tænkt mig at gå i dagens kildekode, som er tilgængelig allerede er online, og jeg har tænkt mig at gå videre og åbne et program kaldet funktion 0.C, og i funktion nul vi vil se et par ting. I første linjer 18 gennem 23 er min vigtigste funktion. Og nu hvor vi er begyndt at læse kode, som vi ikke skriver på flue, men i stedet har jeg skrevet på forhånd eller at du i et problem sæt måtte modtage have er skrevet i forvejen. En god måde at starte læser en andens kode er at kigge efter den vigtigste funktion. Finde ud af, hvor denne post Pointen er at køre programmet, og følg derefter det logisk derfra. 

Så dette program tilsyneladende udskrifter dit navn efterfulgt af et kolon. Vi bruger derefter getString fra CS50 biblioteket at få en snor, eller et ord eller en sætning fra brugeren ved tastaturet. Og så er der dette ting her-- PrintName. 

Nu PrintName er ikke en funktion, der kommer med C. Det er ikke i standard io.h. Det er ikke i CS50.h. Det er snarere i den samme fil. Varsel, hvis jeg rulle ned en bit-- linier 25 til 27-- det er bare en smuk måde at kommentere din kode ved hjælp af stjerner og skråstreger. Dette er en multi-line kommentar, og det er bare min beskrivelse i blå hvad denne funktion gør. 

Fordi der i linjerne 28 til 31, Jeg har skrevet en super simpel funktion hvis navn er PrintName. Det tager hvor mange argumenter ville du sige? Så en argument--, fordi der er en argument anført i parentes. Den type der er String. Hvilket vil sige PrintName er ligesom denne sorte boks eller funktion, der tager som input en streng. 

Og navnet på denne String vil hensigtsmæssigt være navn. Ikke S, ikke N, men navn. Så hvad gør PrintName gøre? Det er dejligt simpelt. Ligesom én linje kode til printf, men tilsyneladende er det udskriver "Hej," så og så. Hvor så og så kommer fra argumentet. 

Nu er det ikke en enorm innovation her. Virkelig, jeg har taget et program, der kunne er blevet skrevet med én linje kode ved at sætte dette op her, og ændret det til noget der indebærer en vis seks eller syv eller deromkring linjer kode hele vejen herned. 

Men det er den praktiserende en princip, som kaldes abstraktion. Kind of indkapsling inden en ny funktion, der har et navn, og bedre endnu dette navn bogstaveligt siger, hvad den gør. Jeg mener printf-- det er ikke særligt beskrivende. Hvis jeg ønsker at oprette en brik, eller hvis jeg ønsker at oprette en funktion der udskriver en persons navn, skønhed gøre dette er, at jeg rent faktisk kan give denne funktion et navn der beskriver, hvad det gør. 

Nu tager i en indgang, Jeg har vilkårligt kaldet navn, men det er også vidunderligt beskrivende i stedet for at være lidt mere generisk ligesom S. og ugyldig, for nu, betyder blot, at denne funktion ikke hånd mig tilbage noget. Det er ikke ligesom getString at bogstaveligt hænder mig tilbage en streng ligesom vi gjorde med de stykker papir med dine klassekammerater i sidste uge, men det har blot en bivirkning. Den udskriver noget til skærmen. 

Så i slutningen af ​​dagen, hvis jeg gør-funktion-0, ./function-0, Vi vil se, at den beder om mit navn. Jeg skriver David, og det former mit navn. Hvis jeg gør det igen med Rob, det kommer til at sige "Hej, Rob." Så en enkel idé, men måske ekstrapolere fra dette mentalt at da programmerne får lidt mere kompliceret, og du ønsker at skrive en luns af kode og opkald, code-- påberåbelse at code-- af nogle beskrivende navn som PrintName, C gør tillade os denne evne. 

Her er et andet simpelt eksempel. For eksempel, hvis jeg åbner en fil fra dag kaldet return.c, mærke til, hvad jeg har gjort her. Det meste af denne hovedfunktion er printf. Jeg først vilkårligt initialisere en variabel kaldet X til nummer 2. Jeg derefter udskrive "x er nu % I "passerer i værdien af ​​x. Så jeg siger bare, hvad det er. 

Nu er jeg bare frimodigt hævder med printf. Jeg cubing denne værdi x, og jeg er gøre det ved at kalde en funktion kaldet terning passerer ix som argument, og derefter gemme output i selve variablen, x. Så jeg clobbering værdien af ​​x. Jeg tvingende den værdi af x med uanset resultatet af ringe denne terning funktion er. Og så vil jeg bare udskrive nogle fluffy ting her at sige, hvad jeg gjorde. 

Så hvad er så terning? Læg mærke til, hvad der er fundamentalt anderledes her. Jeg har givet den funktion et navn som før. Jeg har angivet et navn til et argument. Denne gang er det hedder N i stedet for navn, men jeg kan kalde det, hvad jeg vil. Men det er anderledes. Denne ting til venstre. Tidligere var det hvad søgeord? Drenge. Nu er det naturligvis int. 

Så hvad er måske tage væk? Betragtninger void betegner slags intetheden, og det var tilfældet. PrintName returneres ingenting. Det gjorde det, men det ikke give mig tilbage noget, som jeg kunne sætte på venstre side af et lighedstegn ligesom jeg har gjort her på linie 22. 

Så hvis jeg siger, til på linje 30, hvad er det sandsynligvis indebærer om, hvad terning gør for mig? Ja? Den returnerer et heltal. Så det rækker mig tilbage, for eksempelvis et stykke papir som den har skrevet svaret. 2 kubik, eller 3 kubik, eller 4 cubed-- hvad jeg gik ind, og hvordan jeg gennemfører denne? Nå, bare n gange n gange n er, hvordan jeg kunne terning en værdi. Så igen, super enkel idé, men demonstrativ nu, hvordan vi kan skrive funktioner , faktisk havde os tilbage værdier, der kan være af interesse. 

Lad os se på et sidste eksempel her kaldet funktion én. I dette eksempel begynder det at få mere overbevisende. Så i funktion én dette program-- meddelelse i sidste ende kalder en funktion kaldet GetPositiveInt. GetPositiveInt er ikke en funktion i CS50 bibliotek, men vi besluttede vi gerne vil have den til at eksistere. 

Så hvis vi rulle ned senere i filen, mærke til, hvordan jeg gik om at gennemføre få positiv int, og jeg siger, det er mere overbevisende fordi det er en anstændig Antallet af linjer kode. Det er ikke bare en fjollet lille stykke legetøj programmet. Det er faktisk fået nogle fejlkontrol og gøre noget mere nyttigt. 

Så hvis du ikke har set walkthrough videoer, som vi har indlejret i pset1, ved, at det er en type af løkke i C, samme ånd til den slags ting Scratch kan gøre. Og gør siger gøre dette. Udskriv dette ud. Så gå videre og få N-- få en int og gemme det i N, og holde gør det igen og igen og igen, så længe n er mindre end én. 

Så n kommer til at være mindre end en kun hvis mennesket er ikke at samarbejde. Hvis han eller hun er at skrive i 0 eller -1 eller -50, denne løkke vil holde udfører igen og igen. Og i sidste ende mærke, jeg blot returnere værdi. Så nu har vi en funktion det ville har været rart hvis CS50 ville gennemføre i CS50.h og CS50.c for dig, men her kan vi nu gennemføre denne selv. 

Men to kommentarer til nogle af de vigtigste detaljer. En-- hvorfor jeg erklærer int n, tror du, på linje 29 i stedet for bare at gøre det her, som er mere i overensstemmelse med hvad vi gjorde i sidste uge? Ja? En god tanke. Så hvis vi skulle sætte det her, det er som om vi holde erklære det igen og igen. Det er i og for sig selv er ikke problematisk i sig selv, fordi vi kun har brug for værdien én gang og derefter vi kommer til at få en ny alligevel. Men en god tanke. Ja? 

Luk. Så fordi jeg har erklæret n på ledning 29 uden for sløjfen, Det er tilgængelige i hele Hele denne funktion. Ikke de andre funktioner, da n er stadig inde i disse krøllet seler her. Så-- sikker. 

Præcis. Så dette er endnu mere til det punkt. Hvis vi i stedet erklæret n lige her på linie 32, Det er problematisk, fordi gæt hvor ellers jeg har brug for at få adgang til det? På linie 34, og simpel tommelfingerregel er at du kun kan bruge en variabel inde i de seneste krøllede parenteser hvor du erklærede det. 

Desværre, linie 34 er en linje for sent, fordi jeg allerede har lukket den klammeparentes på linje 33 der svarer til den klammeparentes på linie 30. Og så dette er en måde at sige at denne variabel int er virkefelt, så at sige, at kun indenfor af disse krøllede parenteser. Det bare ikke eksisterer uden for dem. 

Så ja, hvis jeg gør det forkert, lad mig gemme koden som det fejlagtigt er-- skrevet. Lad mig gå videre og gør funktion-1 og notice-- fejl. Anvendelse af sort identifikator n på linje 35, som er lige her. Og hvis vi rulle op yderligere en anden. Anvendelse af sort identifikator n på linje 34. 

Så compiler, Dunk, er at bemærke, at det bare eksisterer ikke, selvom klart det er der visuelt. Så en simpel fix erklære det der. 

Lad mig nu rulle til toppen af ​​filen. Hvad springer ud på dig som være lidt anderledes fra de ting, vi så på i sidste uge? Ikke alene har jeg navn, ikke kun gøre Jeg har nogle skarpe omfatter op toppen, Jeg har noget, jeg kalde en prototype. Nu ser frygtelig svarer til, hvad vi lige så et øjeblik siden på linie 27. 

Så lad os slutte fra en anden fejlmeddelelse, hvorfor jeg har gjort dette. Lad mig gå videre og slette disse linjer der. Og så ved vi intet om prototype. Remake denne fil. Gør funktion én. Og nu, damn, fire fejl. Lad os rulle op til den første. 

Implicit erklæring af funktionen få positiv int er ugyldig i C99. C99 betyder blot 1999 version af sproget C, hvilket er, hvad vi faktisk bruger. Så hvad betyder dette? Nå C-- og mere specifikt C compilers-- er temmelig dumme programmer. De skal blot vide, hvad du har fortalte dem, og det er faktisk tematisk fra sidste uge. 

Problemet er, at hvis jeg går om at gennemføre navn op her, og jeg kalder en funktion kaldet GetPositiveInt her på linie 20, denne funktion teknisk ikke eksistere, indtil compileren ser linie 27. Desværre compiler er gøre tingene top, ned, venstre, højre, , fordi det ikke har set den gennemførelse af GetPositiveInt, men det ser du forsøger at bruge det op her, det bare at gå til bail-- yell på dig med en fejl message-- måske kryptisk, og faktisk ikke kompilere filen. 

Så en såkaldt prototype op her er ganske vist overflødig. Bogstaveligt talt, gik jeg ned her, og jeg kopierede og indsat dette, og jeg sætte det op her. Void ville være mere korrekt, så vi vil bogstaveligt kopiere og indsætte det denne gang. Jeg bogstaveligt talt kopieret og indsat det. Virkelig ligesom ligesom en brød krumme. 

En lille fingerpeg om compiler. Jeg ved ikke, hvad dette betyder endnu, men jeg lover at du at det vil eksistere sidst. Og det er grunden til dette line-- i linje 16-- slutter med et semikolon. Det er afskediget af design. Ja? 

Hvis du ikke linke din bibliotek til-- åh, godt spørgsmål. Sharp inkluderer header fil optagelser. Behov for at være-- burde næsten altid være helt i top af filen til en similar-- for nøjagtig den samme grund, ja. Fordi i standard io.h er bogstaveligt talt en linje som dette, men med ordet printf og med sine argumenter og dens tilbagevenden type. Og så ved at gøre skarp indeholde op her, hvad du er bogstaveligt talt at gøre er at kopiere og indsætte indholdet af en anden skrev op øverst. Derved cluing din kode i den omstændighed, at disse funktioner findes. Ja? 

Absolut. Så en meget klog og korrekt løsning ville være, ved du hvad? Jeg ved ikke, hvad en prototype er, men jeg kender hvis jeg forstår, at C er bare stum og nytænker top til bund. Jamen lad os give det hvad det vil. Lad os skære den kode, indsæt det op top, og nu skubbe vigtigste dernede. Dette ville også løse problemet. 

Men du kan meget nemt komme op med et scenarie, hvor et behov for at ringe til B, og måske B kalder tilbage til A. Denne er noget, der hedder rekursion, og vi vil komme tilbage til. Og det kan eller ikke kan være en god ting, men du kan helt sikkert bryde denne løsning. 

Og i øvrigt ville jeg hævder stilmæssigt, især når dine programmer bliver denne lange og denne lange, det er bare super praktisk at sætte vigtigste øverst fordi det er de ting mest programmører kommer til at bekymre sig om. Og så det er en lidt renere, velsagtens, at gøre det på den måde Jeg oprindeligt gjorde det med en prototype selv selvom det ser lidt overflødig ved første øjekast. Ja? Beklager, kan du sige det højere? 

Hvis du skifter placeringen af ​​den gennemførelse og prototypen? Så det er et godt spørgsmål. Hvis du igen erklære dette ned her, lad os se hvad der sker. Så hvis jeg sætter det ned her, du siger. Åh, undskyld. Louder? Endnu højere. Åh, godt spørgsmål. Ville det ugyldiggøre funktion? Du ved, efter alle disse år, jeg har aldrig sat en prototype bagefter. Så lad os gøre gøre funktion-1 efter at gøre det. 

[Mumler] David J. MALAN: Åh, vent. Vi har stadig nødt til at sætte alt op toppen. Så lad os gøre det op her, hvis jeg forstå dit spørgsmål korrekt. Jeg sætter alt, herunder prototypen ovenfor vigtigste, men jeg lægger prototypen under implementeringen. 

Så hvis jeg laver en, jeg får tilbage en error-- ubrugte variabel n. Åh, der. Tak. Lad os se, får vi slippe af med dette. Det er en anden fejl, så lad os se bort fra dette. Lad os virkelig hurtigt omdannede dette. 

OK, så data ikke argument bruges af format String N-- Åh, det er fordi Jeg skiftede til disse her. Okay, vi ved, hvad svaret går til-- okay, her vi gå. Ah, tak for det positive. Okay, vil jeg rette denne kode after-- ignorere denne fejl da dette var-- det virker, er svaret. 

Så det ikke overskrive hvad du lige har gjort. Jeg formoder compileren er skrevet på en sådan måde at det ignorerer din prototype fordi kroppen, så at sige, af funktionen allerede blevet gennemført højere oppe. Jeg ville være nødt til rent faktisk konsultere vejledningen til compiler at forstå, hvis der er nogen andre implicit, men ved første øjekast bare ved at prøve og eksperimentere, der synes at være nogen effekt. Godt spørgsmål. 

Så lad os gå videre nu, bevæger sig væk fra bivirkninger, som er funktioner, der gør noget lignende visuelt på skærmen med printf, men returnerer ikke en værdi. Og funktioner, der har til gengæld værdier som vi lige har set et par af. Vi har allerede set denne begrebet rækkevidde, og vi vil se det igen og igen. Men for nu, igen, bruge tommelfingerregel at der kun kan bruges en variabel indersiden af ​​den senest åbnede og lukkede krøllede parenteser, som vi så i det pågældende eksempel. 

Og som du har påpeget, der er en ability-- du kunne løse nogle af disse problemer ved at sætte en variabel globalt på toppen af ​​en fil. Men i næsten alle tilfælde vi ville rynke panden på det, og faktisk ikke engang gå ind i denne løsning for nu. Så for nu, takeaway er, at variabler har denne opfattelse af anvendelsesområdet. 

Men lad os nu se på en anden tør måde faktisk ser på nogle temmelig interessant gennemførelse detaljer. Hvordan vi kan repræsentere oplysninger. Og vi allerede set på dette i den første uge af klassen. Ser man på binære filer, og minde os selv om decimal. 

Men husker fra sidste uge, at C har forskellige datatyper og klaser mere, men den mest nyttige dem for nu kunne være disse. En char, eller karakter, hvilket sker at være en byte, eller otte bit alt. Og det er at sige, at størrelsen af en char er blot én byte. En byte er otte bits, så det betyder, at vi kan repræsentere hvor mange tegn. Hvor mange bogstaver eller symboler på tastaturet hvis vi har en byte eller otte bits. Tænk tilbage til uge nul. Hvis du har otte bits, hvor mange samlede værdier kan du repræsenterer med mønstre af nuller og ettaller? En-- mere end det. Så i alt 256, hvis du begynde at tælle fra nul. Så hvis du har otte bits-- så hvis vi havde vores binære løg op her igen, vi kunne slukke for disse pærer på og fra i en af ​​256 unikke mønstre. 

Nu er det en smule problematisk. Ikke så meget for engelsk og romanske sprog, men bestemt når man indfører for Eksempelvis asiatiske sprog, som har langt flere symboler end lignende 26 bogstaver i alfabetet. Vi faktisk kan have behov for mere end en byte. Og heldigvis i de senere år har samfundet vedtagne andre standarder, som bruger mere end én byte per opladning. 

Men for nu i C, standard er blot én byte eller otte bits. Et heltal, i mellemtiden, er fire byte, også kendt som 32 bit. Hvilket betyder, hvad der er den størst mulige nummer vi kan repræsentere med en int tilsyneladende? Med en milliard. Så det er fire milliarder give eller tage. 2 til 32th magt, hvis vi antage nogen negative tal og bare bruge alle positive tal, det er fire milliarder give eller tage muligheder. En svømmer, i mellemtiden, er en anden type af datatype i C. Det er stadig et tal, men det er et reelt tal. Noget med et komma. Og det viser sig, at C bruger også fire bytes at repræsentere kommeværdier. 

Desværre hvor mange flydende point værdier er der i verden? Hvor mange reelle tal er der? Der er en uendelig nummer, og for den sags skyld Der er et uendeligt antal heltal. Så vi er allerede slags grave os et hul her. Hvorved tilsyneladende computers-- på mindst programmer skrevet i C på dem-- kan kun tælle som højt som fire milliarder give eller tage, og kommeværdier kan kun tilsyneladende har nogle begrænset mængde præcision. Kun så mange cifre efter deres kommaet. 

Fordi, selvfølgelig, hvis du kun har 32 bits, Jeg ved ikke, hvordan vi kommer til at gå om repræsenterer reelle numbers-- sandsynligvis med forskellige typer af mønstre. Men der er helt sikkert et endeligt Antallet af sådanne mønstre, så også her, det er problematisk. 

Nu kan vi undgå lidt problemet. Hvis du ikke bruger en float, du kunne bruge en dobbelt i C, som giver dig otte bytes, hvilket er måde flere mulige mønstre af nuller og dem. Men det er stadig begrænset, som vil at være problematisk, hvis du skriver software til grafik eller fancy matematiske formler. Så du kan faktisk ønsker at tælle op større end. En lang long-- dumt named-- er også otte byte, eller 64 bit, og det er dobbelt så lang som en int, og det er for en lang heltal værdi. 

Sjov fact-- hvis en int er fire bytes, hvor lang tid er en lang i C typisk? Også fire bytes, men en lang lang er otte bytes, og det er af historiske årsager. 

Men takeaway nu er bare, at data har at være repræsenteret i et computer-- der er en fysisk enhed med elektricitet, Det er generelt kører disse nuller og ones-- med begrænsede mængder af præcision. Så hvad er problemet så? 

Nå der er et problem af heltalsoverløb. Ikke bare i C, men i computere i almindelighed. For eksempel, hvis dette er en byte værd en bit-- så hvis dette er otte bit-- alle der er nummer et. Hvilket nummer er det repræsenterer hvis vi antager det er alle positive værdier i binær? 

255, og det er ikke 256, fordi nul er det laveste antal. Så 255 er den højeste én, men problemet er Antag at jeg ønskede at tilvækst denne variabel, anvender otte bit i alt hvis jeg ønsker at forøge det. 

Nå, så snart jeg tilføjer en én til alle disse dem, kan du måske forestille visually-- bare som at bære den ene med decimals-- noget kommer til at flyde til venstre. Og ja, hvis jeg føje nummeret om en til, hvad der sker i binær er, at det flyder tilbage til nul. 

Så hvis du kun use-- ikke en int, men en enkelt byte til at tælle heltal i et program, ved default-- så snart du kommer til 250, 251, 252, 253, 254, 255-- 0 kommer efter 255 der er sandsynligvis, hvad ikke en bruger kommer til at forvente. 

Nu i mellemtiden i floating point verden, du også har et lignende problem. Ikke så meget med den største number-- selvom det er stadig et problem. Men med mængden af ​​præcision at du kan repræsentere. Så lad os tage et kig på dette eksempel her også fra dagens kilde code-- float-0.c. 

Og bemærk, det er en super simpelt program, der bør tilsyneladende udskrive hvilken værdi? Hvad vil du satse dette vil udskrive selvom der er lidt af ny syntaks her? Så forhåbentlig 0.1. Så svarer til en tiendedel fordi jeg gør 1 divideret med 10. Jeg lagre svaret i en variabel kaldet f. Denne variabel er af typen float, som er et nøgleord, jeg netop har foreslået eksisterede. 

Vi har ikke set det før, men Dette er sådan en pæn måde i printf at angive, hvor mange cifre, du ønsker at se efter et komma. Så denne notation betyder bare det her er en pladsholder. Det er til et decimaltal værdi, og åh, ved den måde, vise det med kommaet med et tal efter kommaet. Så det er det antal betydende cifre, så at sige, som du måske ønsker. 

Så lad mig gå videre og gøre gøre float-0, ./float-0, og tilsyneladende 1 divideret med 10 er 0,0. Nu, hvorfor er dette? 

Nå igen, er computeren tager mig bogstaveligt, og jeg har skrevet 1 og jeg skrevet 10, og tage et gæt hvad er det antaget datatype for de to værdier? En int, det er teknisk noget lidt anderledes. Det er typisk en lang, men det er i sidste ende en integreret værdi. Ikke en floating point værdi. 

Hvilket vil sige, at hvis dette er en int, og dette er en int, Problemet er, at computeren ikke har mulighed for til endda gemme det kommaet. Så når du gør 1 divideret ved 10 hjælp af heltal for både tæller og nævner, bør svaret være 0.1. Men computer-- fordi de er integers-- ikke ved, hvad de skal gøre med den 0.1. 

Så hvad er det tydeligt gør? Det er bare at smide det væk, og hvad jeg ser i sidste ende er 0,0 kun fordi jeg insisterede på, at printf vise mig én decimal. Men problemet er, at hvis du opdele et heltal med et tal, du vil get-- definition af C-- et heltal. Og det kommer ikke til at gøre noget rart og bekvemt ligesom runde det op til nærmeste op eller ned. Det kommer til at afkorte alt efter kommaet. 

Så bare intuitivt, hvad er sandsynligvis et fix? Hvad er den enkleste løsning her? Ja? Præcis. Hvorfor vi ikke bare behandle disse som kommeværdier effektivt gøre dem til flåd eller double. Og nu, hvis jeg gør flåd-0, eller hvis jeg kompilere flåd-1, som er identisk med hvad var lige foreslået. Og nu gør jeg flåd-0, nu får jeg min 0.1. 

Nu er dette er fantastisk. Men nu har jeg tænkt mig at gøre noget lidt anderledes. Jeg er nysgerrig efter at se, hvad der er virkelig foregår under kølerhjelmen, og jeg har tænkt mig at udskrive denne ud til 28 decimaler. Jeg vil virkelig se 0.1000-- en infinite-- [Uhørligt] 27 nuller efter at 0.1. 

Jamen så lad os se, om det er hvad jeg faktisk får. Gør flåd-0 samme fil. ./floats-0. Lad os zoome ind på den dramatiske svar. I al den tid, du har været tænker 1 divideret med 10 er 10%, eller 0,1. Det er det ikke. Mindst så vidt computers berørt. 

Nu why-- OK, det er komplet ligger 1 divideret med 10 er 0,1. Men why--, der ikke er takeaway i dag. Så hvorfor computeren tænker, i modsætning til alle os i rummet, at 1 divideret med 10 er faktisk, at skøre værdi? Hvad er den computer, gør tilsyneladende? Hvad er det? 

Det er ikke overløb, per se. Overflow er typisk når du wrap omkring en værdi. Det er dette nummer af unøjagtighed i en kommatalsværdi hvor du kun har 32 eller måske endda 64 bit. Men hvis der er en uendelig Antallet af fast numbers-- numre med decimaler og numre thereafter-- sikkert du kan ikke repræsentere dem alle. Så computeren har givet os den tætteste match til den værdi, det kan repræsentere ved hjælp af denne mange bit til den værdi, jeg rent faktisk ønsker, hvilket er 0,1. 

Desværre, hvis du begynde at gøre matematik, eller du begynde at inddrage disse former for flydende point værdier i vigtige programs-- finansiel software, militær software-- noget hvor opfattelsen er sandsynligvis temmelig vigtigt. Og du begynder at tilføje numre som dette, og start kører denne software med virkelig store indgange eller for masser af timer eller partier dage eller masser af år, disse bittesmå fejl sikkert kan tilføje op over tid. 

Nu som en sidebemærkning, hvis du nogensinde har set Superman 3 eller Office Space og du måske husker hvordan de fyre stjal en masse penge fra deres computer ved hjælp kommeværdier og tilføje op den lille rester, forhåbentlig, film nu giver mere mening. Dette er, hvad de var hentyder til i den film. Det faktum, at de fleste selskaber ville ikke se efter et vist antal af decimaler, men de er brøkdele af cent. Så du begynder at tilføje dem op, du begynder at gøre en masse penge på din bankkonto. Så det er Office Space forklaret. 

Nu desværre ud over Office Space, der er nogle legitimt bekymrende og væsentlige påvirkninger af disse former for underliggende design beslutninger, og faktisk en af ​​grundene vi bruger C i løbet er så at du virkelig har denne jord up forståelse af, hvordan computere arbejde, hvordan software fungerer, og ikke tage noget for givet. 

Og faktisk desværre selv med denne grundlæggende forståelse, vi mennesker begår fejl. Og hvad jeg tænkte jeg ville dele er dette otte minutter video her taget fra en Modern Marvels episode, som er en pædagogisk udstilling om, hvordan tingene fungerer der maler to billeder af, hvornår en uretmæssig brug og forståelse af kommeværdier ført til en vis betydelig uheldige resultater. Lad os tage et kig. [VIDEOAFSPILNING] -Vi Nu vende tilbage til "Engineering Katastrofer "på Modern Marvels. Computere. Vi har alle kommet til at acceptere den ofte frustrerende problemer, fik med dem-- bugs, vira, og software glitches-- til små priser til at betale for bekvemmelighed. Men i high tech og høj hastighed militære og rum programansøgninger, den mindste problem kan forstørres og blive til en katastrofe. 

Den 4. juni 1996 videnskabsfolk forberedt at lancere en ubemandet Ariane 5 raket. Det var i færd med videnskabelig satellitter designet præcis, hvordan det at etablere Jordens magnetfelt interagerer med solvind. Raketten blev bygget til Den Europæiske Rumorganisation, og løftes fra sit anlæg på kysten af ​​Fransk Guyana. 

-På Omkring 37 sekunder inde flyvningen, de først bemærket noget var galt. At dyserne var drejelig på en måde, de burde virkelig ikke. Omkring 40 sekunder inde i flyvningen, tydeligt køretøjet var i problemer, og det er, når de gjorde beslutningen om at ødelægge det. Sortimentet sikkerhed officer, med enorme indvolde, trykkede på knappen og sprængte raket, før det kunne blive en fare for den offentlige sikkerhed. 

-dette Var jomfru sejlads af Ariane 5, og dens ødelæggelse tog placere på grund af fejl indlejret i raket software. -Problemet På Ariane var, at der var et nummer, der kræves 64 bit til at udtrykke, og de ønskede at konvertere det til et 16-bit tal. De antog, at antallet var aldrig vil være meget store. Det fleste af disse cifre i 64-bit tal var nuller. De var forkert. 

-Den Manglende evne af en softwareprogram til at acceptere den slags tal, der genereres ved en anden var ved roden af ​​den fiasko. Softwareudvikling var blevet en meget kostbare del af ny teknologi. Ariane 4 raket havde været meget vellykket. Så meget af den software skabt til det blev også anvendt i Ariane 5. 

-Den Grundlæggende problem var, at Ariane 5. Var faster-- accelereret hurtigere, og softwaren ikke havde tegnede sig for det. 

-Den Ødelæggelse af raketten var en enorm økonomisk katastrofe. Alle på grund af et minut softwarefejl. Men det var ikke den første time data konvertering problemer havde plaget moderne raket teknologi. 

-I 1991 med starten af den første Golfkrig, Patriot missil oplevet en lignende art af et antal konvertering problem. Og som et resultat 28 people-- 28 Amerikanske soldiers-- blev dræbt, og omkring hundrede andre såret. Når Patriot, som skulle at beskytte mod indkommende Scuds, undladt at affyre et missil. 

-Når Irak invaderede Kuwait, og Amerika lanceret Desert Storm i begyndelsen af ​​1991, Patriot missil batterier blev indsat at beskytte Saudi-Arabien og Israel fra irakiske Scud missilangreb. The Patriot er en amerikansk mellemdistance overflade-til-luft-system fremstilles af Raytheon selskab. 

-Den Størrelsen af ​​Patriot interceptor itself-- det er omkring cirka 20 meter lang, og det vejer omkring 2.000 pounds. Og det bærer et sprænghoved på omkring, Jeg tror, ​​det er omkring 150 pounds. Og sprænghoved selv er en højeksplosiv, som har fragmenter omkring ham. Så kabinet sprænghoved er designet til at fungere som en hagl. 

-De Missiler udføres fire pr container, og transporteres af en sættevogn. 

-The Patriot anti-missil-system går tilbage mindst 20 år nu. Det blev oprindeligt designet som et luftforsvar missil at nedskyde fjendtlige fly. I den første Golfkrig da krigen kom, hæren ønskede at bruge det til nedskyde Scuds, ikke fly. Den irakiske luftvåben var ikke så meget af et problem, men hæren var bekymret Scuds. Og så de forsøgte at opgradere Patriot. 

-Intercepting En fjende missil rejser på Mach 5 skulle være udfordrende nok. Men når Patriot blev hastet i brug, Hæren var ikke bekendt med en irakisk ændring, gjorde deres scuds næsten umuligt at det. 

Hvad er der sket er det Scuds at kom ind var ustabil. De var vaklende. Årsagen til dette var den Iraqis-- For at få 600 km ud af en 300 kilometer rækkevidde missile-- tog vægt ud af den forreste sprænghoved, og gjorde sprænghoved lysere. Så nu Patriot forsøger at komme på Scud, og det meste af time-- det overvældende flertal af den time-- det ville bare flyve af Scud. 

-Når Patriot systemoperatører indså Patriot savnede sit mål, de detonerede Patriot sprænghoved at undgå mulige tab, hvis det fik lov til at falde til jorden. 

-Det Var hvad de fleste folk så som store ildkugler på himlen, og misforstået som aflytninger af Scud sprænghoveder. 

-Selv I nattehimlen, Patriots syntes at være vellykket ødelægge Scuds på Dhahran der kunne være ikke fejl af dens ydeevne. Der Patriot radar-system mistet overblikket over et indkommende Scud og aldrig iværksat på grund til en software fejl. 

Det var israelere, der først opdagede at jo længere systemet var på, jo større tidsforskel blev. På grund af et ur indlejret i systemets computer. 

-Omkring To uger før tragedien i Dhahran, israelerne rapporteret til forsvarsministeriet at systemet var ved at miste tid. Efter ca. otte timer af løb, bemærkede de at systemets blive mærkbart mindre nøjagtige. Forsvarsministeriet reagerede ved fortæller alle Patriot batterier ikke forlade systemerne i lang tid. De har aldrig sagt, hvad en lang tid var. 8 timer 10 timer, tusind timer. Ingen vidste. 

-The Patriot batteri stationeret på kasernen på Dhahran og dets mangelfulde interne ur havde været i over 100 timers om natten den 25. februar. 

-Det Spores tid til en nøjagtighed på omkring en tiendedel af et sekund. Nu er en tiendedel af et sekund er et interessant tal fordi det ikke kan udtrykkes i binær nøjagtigt, som betyder det ikke kan udtrykkes nøjagtigt i en moderne digital computer. Det er svært at tro, men bruge dette som et eksempel. 

Lad os tage det nummer en tredjedel. En tredjedel kan ikke være udtrykkes som et decimaltal nøjagtigt. En tredjedel er 0,333 foregår til uendeligt. Der er ingen måde at gøre det med absolut nøjagtighed i en decimal. Det er præcis den slags problemer der skete i Patriot. Jo længere systemet kørte, den værre tidspunkt fejlen blev. 

-Efter 100 timers drift, fejl i tid var kun omkring en tredjedel af et sekund. Men med hensyn til målretning en missil rejser på Mach 5, det resulterede i en tracking fejl på over 600 meter. Det ville være en fatal fejl for soldaterne i Dhahran. 

Hvad skete der et Scud lancering var opdaget af satellitter tidlig varsling, og de vidste en Scud kommer i deres generelle retning. De vidste ikke, hvor det kommer. Det var nu op til radaren komponent af Patriot-systemet forsvare Dhahran at lokalisere og holde spor af den indkommende fjendtlige missiler. 

-Den Radar var meget smart. Det ville faktisk spore position Scud og derefter forudsige, hvor det sandsynligvis ville være næste gang radar sendes en impuls ud. Det blev kaldt intervallet porten. 

-Så Når Patriot beslutter tilstrækkelig tid har bestået for at gå tilbage og tjekke den næste placering til dette detekteret objekt det går tilbage. Så når det gik tilbage til den forkerte sted, det så ser noget objekt. Og beslutter, at der ikke var noget objekt. At der var en falsk detektion og det falder sporet. 

-Den Indkommende Scud forsvandt fra radarskærmen, og sekunder senere, hamrede ind i kasernen. Den Scud dræbte 28. Det var den sidste fyret under den første Golfkrig. Tragisk, den opdaterede software ankom ved daggry den følgende dag. Den software fejl havde været fastsat, lukning et kapitel i den urolige historie Patriot missil. 

[END VIDEO PLAYBACK] 

David J. MALAN: Det er det for CS50. Vi vil se dig på onsdag. 

[Musik spiller]