[Musikk spilles] DAVID J. MALAN: All right. Dette er CS50, og denne er starten på uke to. Så la oss begynne i dag med en bug. En bug, selvfølgelig, er en feil i et program, og du får veldig kjent med dette konseptet hvis du aldri har programmert før. pset0 og nå pset1. Men la oss vurdere noe litt enkelt i begynnelsen. Dette programmet her at jeg kastet sammen på forhånd, og jeg hevder at dette skal skrives ut 10 stjerner på skjermen ved hjelp av printf, men det er tydeligvis buggy på noen måte. 

Gitt at spesifikasjon som det skal skrives ut 10 stjerner, men det gjør ikke tilsynelatende, hva ville du påstår er feilen? Yeah? Så det er en av ved en feil, og hva mener du med det? OK. Utmerket. Så vi har spesifisert en starte verdi på null for jeg, og vi har spesifisert en n verdi på 10, men vi har brukt mindre enn eller lik. Og på grunn av at dette er to tegn og ikke bare ett symbol, som i en matte bok, er at du ikke har en måte å uttrykke en karakter tilsvarende. 

Så det betyr mindre enn, men hvis du begynner å telle på null, men du telle hele veien opp gjennom og lik 10, du er selvfølgelig kommer til å teller 11 ting totalt. Og så kommer du til å skrive ut 11 stjerner. Så hva kan være en løsning på dette? Yeah? 

Så bare justere mindre enn eller lik bare være mindre enn, og det er, jeg hevder, kanskje en annen løsning, også. Hva kan du ellers gjøre? Yeah? 

Så begynn tilsvarer den til 1, og la er mindre enn eller lik. Og ærlig jeg vil hevde at for et typisk menneske, dette er trolig mer ukomplisert. Begynne å telle på en og telle opp gjennom 10. I hovedsak gjøre hva du mener. 

Men realiteten er i programmering, som vi har sett, dataforskere og programmerere generelt ikke begynne å telle på null. Og så er det helt greit en gang du blir vant til det. Tilstanden din vil generelt være noe sånt som mindre enn. Så rett og slett en logisk feil som vi kunne nå fikse og til slutt rekompilere dette og få bare 10. 

Vel hva med denne feilen her? Her, igjen, jeg påstår at jeg har et mål om å skrive ut 10 stars-- én per linje denne gangen, men det gjør det ikke. Før vi foreslå hva reparasjonen er, hva betyr dette skrive ut visuelt hvis jeg skulle kompilere og kjør dette programmet tror du? Yeah? 

Star. Så alle stjernene på den samme linje er hva jeg har hørt, og deretter den nye linjen karakter. Så la oss prøve det. Så gjør buggy-en, gå inn, og jeg ser klang kommandoen som vi snakket om forrige gang. ./buggy-en, og faktisk jeg ser alle 10 stjerner på samme linje selv om jeg hevder i min spesifikasjonen bare en kommentar toppen koden som jeg hadde tenkt å gjøre én per linje. Men dette ser riktig. 

Nå linje 15 ser det ut som jeg er skrive ut en stjerne, og deretter linje 16 det ser ut som jeg er utskrift en ny linje karakter, og de er begge rykket så Jeg er på innsiden av løkken tydelig. Så bør ikke jeg gjøre stjerne, ny linje, stjerne, ny linje, stjerne, ny linje? Ja? 

Ja, i motsetning til et språk som Python, hvis du er kjent, innrykk ikke saken til datamaskinen. Det betyr bare til den menneskelige. Så mens her har jeg oppfunnet linjer 15 og 16-- som ser vakkert, men datamaskinen ikke bryr seg. Datamaskinen bryr seg om faktisk å ha klammeparentes rundt disse linjer med kode. 

Slik at det er clear-- akkurat som i Scratch-- at disse to linjer med kode bør bli henrettet. Som en av de gule Scratch puslespill stykker igjen og igjen og igjen. 

Så nå hvis jeg å kjøre dette program-- ./buggy-2-- Hm. Jeg har en feil nå. Hva gjorde jeg glemmer å gjøre? Ja, så jeg fikk ikke kompilere den. Så gjør buggy-2. Ingen slik fil fordi jeg gjorde ikke faktisk kompilere den andre versjonen. Så nå interessant undeclared variable-- ikke to. Vi gjør en. Gjør buggy-1-- ./buggy-1-- og nå hver av dem er på samme linje. 

Nå er det et unntak fra denne antatte krav av meg at du trenger disse klammeparentes. Når er det faktisk ok-- hvis du har lagt merke til i seksjon eller textbooks-- å utelate klammeparentes? Yeah? 

Nettopp. Når det bare er én linje med kode som du ønsker å bli forbundet med den løkke som i vårt første eksempel. Det er helt legitimt å utelate klammeparentes akkurat som en slags bekvemmelighet fra kompilatoren til deg. Yeah? Godt spørsmål. Ville det bli betraktet som en feil stil? Vi ville promote-- som i CS50 style guide, URL som er i pset1-- som alltid bruke klammeparentes. Gjerne hvis du er ny på programmering. Realiteten er at vi ikke er kommer til å forby deg fra å gjøre disse bekvemmeligheter. Men hvis du bare får i sving på ting, absolutt bare alltid bruke krøllete bukseseler til du får taket på det. Godt spørsmål. 

Greit. Så det da var en bug. I det minste i noe ganske enkel. Og enda du kanskje tror dette er ganske rudimentær, ikke sant? Dette er liksom den første uken av å se på språket lignende, se dine bugs der. Men realiteten disse er faktisk representative av noen ganske skremmende problemer som kan oppstå i den virkelige verden. 

Så noen av dere kanskje husker hvis du følger tech nyheter, eller kanskje til og med fanget nyss om dette i februar av det siste året at Apple hadde gjort litt av en feil i begge iOS, operativsystemet på sine telefoner, og også Mac OS, operativsystemet på sine stasjonære og bærbare datamaskiner. Og du så slike overskrifter som dette. Og etterpå, Apple lovet å fikse denne feilen, og svært raskt fikse det i iOS, men så til slutt løst det i Mac OS også. 

Nå er ingen av disse overskriftene alene egentlig avsløre hva det underliggende problemet var, men feilen ble til slutt redusert til en feil i SSL, Secure Sockets Layer. Og lang historie kort, Dette er programvaren at våre nettlesere og andre programvare som brukes til å gjøre hva? 

Hvis jeg sa at SSL er involvert, når du besøke en URL som starter med HTTPS, hva da kanskje SSL være relatert til? Kryptering. Så vi vil snakke om dette i de kommende dagene. Kryptering, kunsten scrambling informasjon. 

Men lang historie kort, Apple gang siden hadde gjort en feil i gjennomføringen av SSL, den programvare som til slutt implementerer URLer som HTTPS eller maks tilkoblinger der også. Resultatet av dette er at tilkoblinger kan potensielt bli fanget opp. Og dine tilkoblinger var ikke nødvendigvis kryptert hvis du hadde noen bad guy i mellom du og destinasjonen nettstedet som visste hvordan å dra nytte av dette. 

Nå Apple slutt postet en løsning på dette til slutt, og beskrivelsen av sine fikse var dette. Sikker transport unnlatt å validere ektheten av tilkoblingen. Emisjonen ble rettet opp av gjenopprette manglende validering trinn. 

Så dette er en veldig hånd bølget forklaring for bare å si at vi skrudd opp. Det er bokstavelig talt en linje med kode som var buggy i gjennomføringen av SSL, og hvis du går på nettet og søke etter dette du kan faktisk finne den opprinnelige kildekoden. For eksempel er dette et skjermbilde av bare en del av en forholdsvis stor fil, men dette er en funksjon tilsynelatende kalles SSL verifisere tegn serveren nøkkelutveksling. Og det tar en haug med argumenter og innganger. Og vi kommer til å fokusere for mye på minutia der, men hvis du fokuserer på koden inne av at øverste function-- la oss zoome inn på det. Du har kanskje allerede mistenker hva feilen kan være selv om du har ingen anelse til syvende og sist hva du ser på. Det er på en måte en anomali her, som er hva? 

Ja, vet jeg egentlig ikke liker utseendet på to goto mislykkes. Oppriktig, jeg egentlig ikke vet hva goto mislykkes midler, men som har to av dem rygg mot rygg. Som bare slags gnir meg intellektuelt på feil måte, og faktisk hvis vi zoome inn på bare disse linjene, er dette C. 

Så mye av Apples kode er selv skrevet i C, og dette tilsynelatende er virkelig equivalent-- ikke til at ganske innrykk versjonen, men hvis du anerkjenner det faktum at det er ingen klammeparentes, hva Apple virkelig skrev var kode som ser som dette. Så jeg har zoomet ut og jeg bare fast innrykk i den forstand at hvis det er ingen klammeparentes, at andre goto mislykkes som er i gult kommer til å utføre uansett. Det er ikke forbundet med hvis betingelsen ovenfor. 

Så selv igjen, ikke hvis du gjør ganske forstå hva dette kan muligens være å gjøre, vet at hver av disse conditions-- hver av disse linjer er et svært viktig skritt i ferd med å kontrollere Hvis dataene er faktisk kryptert. Så hopper over en av disse trinn, ikke den beste ideen. 

Men fordi vi har denne andre goto mislykkes i gult, og fordi når vi slags estetisk flytte den til venstre der det logisk er i øyeblikket, hvilken betyr dette for linjen av koden under den andre goto mislykkes ville du tror? Det er alltid kommer til å bli hoppet over. Så GOTO blir generelt mislikt av grunner vi vil virkelig ikke gå inn, og faktisk i CS50 vi pleier ikke å lære dette utsagnet goto, men du kan tenke på goto mislykkes som menings go hoppe til noen annen del av koden. 

Med andre ord hoppe over denne siste linjen helt, og så resultatet av denne dumme enkel feil som bare var et resultat av trolig noen kopiere og lime en også mange ganger var at hele sikkerheten til iOS og Mac OS var utsatt for avskjæring av skurkene i ganske lang tid. Inntil Apple endelig løst dette. 

Nå hvis noen av dere er faktisk kjører gamle versjoner av iOS eller Mac OS, du kan gå til gotofail.com som er et nettsted som noen satt opp til hovedsak bestemme programma hvis datamaskinen fortsatt er sårbar. Og ærlig talt, hvis det er, det er nok en god idé å oppdatere telefonen eller Mac på dette punktet. Men der, bare testament til hvor en styrking av disse lavere nivå detaljer og ganske enkle ideer kan virkelig sette til beslutninger og problemer som affected-- i denne case-- millioner av mennesker. 

Nå et ord på administrasjon. Delen vil starte førstkommende søndag. Du vil motta en e-post ved helg om delen, noe som medførte den resectioning prosessen vil begynne hvis du har skjønte du nå har noen nye konflikter. Så dette skjer hvert år, og vi vil romme i dagene som kommer. 

Kontor timer-- gjør holde et øye med denne planen her. Endrer litt denne uken, særlig starttiden og plasseringen, så ta kontakt at før du drar til kontortiden en hvilken som helst av de neste fire nettene. Og nå et ord på vurdering, særlig når du dykke inn problem setter ett og utover. 

Så henhold til spesifikasjonen, disse er vanligvis aksene langs hvilke vi evaluere arbeidet ditt. Omfang refererer til hva grad koden din redskaper funksjonene som kreves etter vår spesifikasjon. , Hvor mye av med andre ord et stykke sett gjorde du bite av. Gjorde du en tredjedel av det, halvparten av det, 100% av det. Selv om det ikke er riktig, Hvor mye fikk du prøve? Så som fanger nivået innsats og beløpet som du litt utenfor Oppgavesettet problemer. 

Correctness-- denne, til hvilken grad, er koden i tråd med vår spesifikasjoner og fri for feil. Så virker det riktig? Hvis vi gir det noen innspill, det gjør det gi oss den produksjonen som vi forventer? Design-- nå er dette den første av de spesielt kvalitative seg, eller de som krever menneskelig skjønn. Og ja, dette er grunnen til at vi har en stab av så mange undervisnings stipendiater og kurs assistenter. I hvilken grad er din kode skrevet godt? 

Og igjen er dette en svært kvalitativ vurdering som vil jobbe med deg på begge veier i ukene som kommer. Slik at når du får ikke bare numeriske score, men også en skriftlig summer eller skrevet tilbakemeldinger, eller skriftlig tilbakemelding på engelske ord. Det er det vi skal bruke til å kjøre deg mot faktisk skriver bedre kode. Og i foredrag og seksjonen vil vi prøve å peke out-- så ofte som vi can-- hva som gjør et program ikke bare korrekt og funksjonelt bra, men også godt designet. Den mest effektive det kan være, eller selv de mest vakre kan det være. 

Hvilket fører oss til stil. Stil til slutt er en estetisk dom. Visste du velge det gode navn på variabler? Har du rykket inn koden din riktig? Ser det bra, og derfor er det lett for et annet menneske å lese din respektive av riktighet. 

Nå generelt per pensum, vi scorer disse tingene på en fem punkts skala. Og la meg hamre inn poenget at et tre er faktisk godt. Svært raskt gjøre folk begynne å gjøre aritmetikk. Når de får en tre av fem på nøyaktighet for noen PSet og de tenker faen, jeg kommer til 60% som i hovedsak er en D eller en E. 

Det er ikke slik vi tenker på disse tallene. Et tre er faktisk godt, og det vi vanligvis forventer i begynnelsen av begrepet er at hvis du får en haug med three's-- kanskje et par messer, et par fours-- eller et par toere, et par fours-- det er et bra sted å starte. Og så lenge vi ser en oppadgående bane over tid, du er i en spesielt god plass. 

Formelen vi bruker for å vekt ting er egentlig dette per pensum, som bare betyr at vi gi mer vekt på korrekthet. Fordi det er svært ofte korrekthet som tar mest tid. Stol på meg nå. Du vil find-- minst i ett pset-- at du tilbringer 90% av tiden din arbeider på 10% av problemet. 

Og alt slags jobber bortsett fra en eller to feil, og de er de feilene som holde deg sent på kvelden. De er de som slags unnslippe deg. Men etter å ha sovet på det, eller deltar kontortid eller stille spørsmål på nettet, er når du kommer til at 100% mål, og det er derfor vi vekt korrekthet mest. Designe en litt mindre, og style litt mindre enn det. Men vær mind-- stil er kanskje den enkleste av disse for å bite av som per stil guide. 

Og nå, en mer alvorlig oppmerksom på akademisk redelighet. CS50 har den uheldige forskjellsbehandling av å være den største produsenten av Ad Board tilfeller nesten hvert år historisk. Dette er ikke fordi studenter jukser i CS50 noe mer så enn noen annen klasse, men på grunn av arbeidets art, det faktum at det er elektronisk, det faktum at vi ser etter det, og det faktum vi er dataforskere, Jeg kan si at vi er dessverre veldig flinke til å oppdage det. 

Så hva betyr dette i reelle termer? Så det, per pensum, kursets filosofi virkelig koker ned til å være rimelig. Det er denne linjen mellom gjøre ett arbeid på egen hånd og får en liten bit av rimelig hjelp fra en venn, og regelrett gjør at arbeidet for din venn, eller sende ham eller henne koden din slik at han eller hun kan rett og slett ta eller låne den ut til høyre. Og som krysser linjen at vi trekkes i klassen. 

Se, pensum i siste instans for linjene at vi trekker som rimelige og urimelig oppførsel, men det virkelig koke ned til kjernen av arbeidet måtte være din egen til slutt. Nå med det sagt, det er en heuristisk. Fordi som du kanskje imagine-- fra kontortiden og det visuelle og videoene vi har vist dermed far-- CS50 faktisk er ment å være så samarbeid og som samarbeidsvillig og som sosial som mulig. Som samarbeids som det er strenge. 

Men med dette sagt, heuristisk, som du ser i pensum, er at når du har noen problem. Du har noen feil i koden din som du ikke kan løse, er det rimelig for deg å vise din kode til noen andre. En venn selv i klassen, en venn sitter ved siden av deg på kontortiden, eller et medlem av personalet. Men de kan ikke vise sin koden din. 

Med andre ord, en svaret på dine question-- Jeg trenger help-- er ikke oh, her er min kode. Ta en titt på denne og utlede fra det hva du vil. Nå, selvfølgelig, det er en måte klart til spill dette system der jeg skal vise deg koden min før har et spørsmål. Du viser meg min koden før har et spørsmål. Men se pensum igjen for finere detaljer om hvor denne grensen går. 

Bare for å nå male bildet og dele så transparent som mulig hvor vi er på de siste årene, dette er antall Ad Board tilfeller at CS50 har hatt over de siste sju årene. Med 14 tilfeller denne siste høst. I forhold til studentene som er involvert, det var 20 noen merkelige studenter dette siste høst. Det var en topp på 33 elevene noen år siden. Mange av dem er dessverre ikke lenger her på campus. 

Studentene er involvert i prosent av den klasse har historisk varierte fra 0% til 5,3%, som bare er å si dette er årlig en utfordring. Og mot dette målet, hva vi ønsker å gjøre er å formidle en at vi dd-- bare FYI sammenligne i en rettferdighet til de studentene som er følger linjen tilsvarende. Vi gjør sammenligne alle gjeldende innleveringer mot alle tidligere oppdrag fra de siste mange år. 

Vi vet også hvordan å Google rundt og finne kode repositories online, diskusjonsfora online, jobbsider online. Dersom en student kan finne det, kan vi sikkert synes det er så mye som vi dessverre gjør. Så hva du vil se i pensum men er dette beklagelse klausulen. Jeg kan sikkert setter pris på, og vi alle har ansatte har gjort kurset som denne eller dette selv over tid, sikkert vet hvordan det er når livet kommer i veien når du har litt sent natt deadline-- ikke bare i denne klassen, men another-- når du er helt utslitt, stressa, har en overdreven antall av andre ting å gjøre. Du vil gjøre på et tidspunkt i livet absolutt en dårlig, kanskje sent natt beslutning. 

Så per pensum, det er denne klausulen, den måten at hvis innen 72 timer etter at noen dårlig avgjørelse, eier du opp til det og nå ut til meg og en av kursets hoder og vi vil ha en samtale. Vi vil håndtere ting internt i håp for det blir mer av en undervisning øyeblikk eller livsvisdom, og ikke noe med spesielt drastiske konsekvenser som du kan se på disse listene her. 

Så det er en veldig alvorlig tone. La oss ta en pause for bare noen få sekunder for å bryte spenningen. 

[Musikk spilles] 

DAVID J. MALAN: Greit, Så hvordan var det for en naturlig overgang? Til dagens primære emner. Den første av disse er abstraksjon. En annen av disse kommer til å bli representasjon av data, som ærlig er en veldig tørr måte å si hvordan kan vi gå om å løse problemer og tenke om å løse problemer? Så du har sett i Scratch, og du har sett kanskje allerede i pset1 med C at du ikke bare kan bruke funksjoner, som printf, at andre mennesker i år tidligere skrev for deg. Du kan også skrive dine egne funksjoner. 

Og selv om du kanskje ikke har gjort dette i C, og ærlig i pset1 du egentlig ikke trenger å skrive din egen funksjon fordi problem-- mens kanskje skremmende på først glance-- du vil se kan til slutt løses med ikke alle at mange linjer med kode. Men med det sagt, i form av å skrive din egen funksjon, innse at C ikke gir du denne evnen. 

Jeg kommer til å gå i dagens kildekode, som er tilgjengelig allerede på nettet, og jeg kommer til å gå videre og åpne opp et program som heter funksjon 0.C, og i funksjon null vi får se et par ting. I første linjene 18 gjennom 23 er min viktigste funksjon. Og nå som vi begynner å lese kode som vi ikke skriver på sparket, men i stedet har jeg skrevet på forhånd eller at du i en oppgavesettet kan få ha blitt skrevet på forhånd. En god måte å starte lese andres kode er å se etter den viktigste funksjonen. Finne ut hvor denne oppføringen Poenget er å kjøre programmet, og deretter følger det logisk derfra. 

Så dette programmet tilsynelatende utskrifter ditt navn etterfulgt av et kolon. Deretter bruker vi GetString fra CS50 biblioteket å få en streng, eller et ord eller en frase fra brukeren ved tastaturet. Og så er det dette ting her-- printname. 

Nå printname er ikke en funksjon som kommer med C. Det er ikke i standard io.h. Det er ikke i CS50.h. Det er heller i samme fil. Legg merke til om jeg ruller nedover en bit-- linjene 25 til 27-- det er bare en pen måte å kommentere koden ved hjelp av stjerner og skråstreker. Dette er en multi-line kommentere, og dette er bare min beskrivelse i blå hva denne funksjonen gjør. 

Fordi i linjene 28 til 31, Jeg har skrevet en super enkel funksjon hvis navn er printname. Det tar hvor mange argumenter ville du si? Så en argument-- fordi det er en argument oppført i parentesen. Typen som er String. Som er å si printname er som denne svarte boksen eller funksjon som tar som input en streng. 

Og navnet på at String beleilig vil være navn. Ikke S, ikke N, men navn. Så hva gjør printname gjøre? Det er fint enkelt. På samme måte som en linje med kode for printf, men tydeligvis det skriver ut "Hei," så og så. Der så og så kommer fra argumentet. 

Nå er ikke dette en stor innovasjon her. Virkelig, har jeg tatt et program som kunne har blitt skrevet med en linje med kode ved å sette dette opp her, og endret det til noe som innebærer noen seks eller syv eller så linjer med kode hele veien ned her. 

Men det er praktiseringen av en prinsipp kjent som abstraksjon. Slags innkapsling av innsiden av en ny funksjon som har et navn, og bedre men det navnet bokstavelig talt sier hva den gjør. Jeg mener printf-- det er ikke særlig beskrivende. Hvis jeg ønsker å lage en puslespill brikke, eller hvis jeg ønsker å opprette en funksjon som skriver ut noen navn, skjønnhet å gjøre dette er at jeg faktisk kan gi den funksjonen et navn som beskriver hva den gjør. 

Nå tar det i en inngang som Jeg har vilkårlig kalt navn, men som også er fantastisk beskrivende stedet for å være litt mer generisk som S. Og ugyldig, for nå, betyr bare at denne funksjonen ikke gi meg tilbake noe. Det er ikke som GetString som bokstavelig talt hendene meg tilbake en streng som vi gjorde med bitene av papir med klassekameratene dine i forrige uke, men den har bare en bivirkning. Den skriver noe til skjermen. 

Så ved slutten av dagen, hvis jeg gjør funksjons-0, ./function-0, vi vil se at den ber om navnet mitt. Jeg skriver David, og det typer ut navnet mitt. Hvis jeg gjør det igjen med Rob, det kommer til å si "Hei, Rob." Så en enkel idé, men kanskje ekstrapolere fra dette mentalt at så programmene dine få litt mer komplisert, og du ønsker å skrive en del av kode og samtale som code-- påberope at code-- av noen beskrivende navn som printname, C gjør råd til oss denne evnen. 

Her er et annet enkelt eksempel. For eksempel, hvis jeg åpne opp en fil fra i dag heter return.c, Legg merke til hva jeg har gjort her. Mesteparten av denne viktigste funksjon er printf. Jeg først vilkårlig initialisere en variabel kalt x til tallet 2. Jeg deretter skrive ut "x er nå % I "passerer i verdien av x. Så jeg sier bare hva det er. 

Nå er jeg bare frimodig hevde med printf. Jeg cubing at verdien x, og jeg er gjøre det ved å kalle en funksjon kalt kube bestått i x som argument, og deretter lagre utdataene i variabelen selv, x. Så jeg clobbering verdien av x. Jeg overstyrer verdien av x med uansett resultatet av ringer denne kuben funksjonen er. Og da jeg bare skrive ut noen fluffy ting her å si hva jeg gjorde. 

Så hva er da kube? Legg merke til hva som er fundamentalt annerledes her. Jeg har gitt funksjonen et navn som før. Jeg har angitt et navn for et argument. Denne gangen det heter n i stedet for navn, men jeg kan kalle det noe jeg ønsker. Men dette er annerledes. Denne saken til venstre. Tidligere var det søkeordet? Gutter. Nå er det åpenbart int. 

Så hva som kanskje ta bort? Mens void betegner slags intet, og det var tilfelle. Printname returnert ingenting. Det gjorde noe, men det gjorde ikke gi meg tilbake noe som jeg kunne sette på venstre side av et likhetstegn som jeg har gjort her på linje 22. 

Så hvis jeg sier til on line 30 hva er det trolig antyde om hva kube gjør for meg? Yeah? Den returnerer et heltall. Så det hender meg tilbake, for eksempel et papirark på hvilke det har skrevet svaret. 2 cubed, eller 3 terninger, eller 4 cubed-- hva jeg gikk inn, og hvordan fikk jeg gjennomføre dette? Vel, akkurat n ganger n ganger n er hvordan jeg kan kube en verdi. Så igjen, superenkel idé, men demonstrative nå hvordan vi kan skrive funksjoner som faktisk hadde oss tilbake verdier som kan være av interesse. 

La oss se på et siste eksempel her kalt funksjon en. I dette eksemplet, det begynner å få mer overbevisende. Så i funksjon en, dette program-- varsel til slutt kaller en funksjon som heter GetPositiveInt. GetPositiveInt er ikke en funksjon i CS50 bibliotek men vi besluttet vi ønsker at det skal eksistere. 

Så hvis vi bla nedover senere i filen, merke til hvordan jeg gikk om å implementere få positiv int, og jeg si det er mer overbevisende fordi dette er en anstendig antall linjer med kode. Det er ikke bare en dum lite leketøy program. Det er faktisk fikk noen feilsjekking og gjøre noe mer nyttig. 

Så hvis du ikke har sett walkthrough videoer som vi har innebygd i pset1, vite at dette er en type løkke i C, ligner i ånden til den slags ting Scratch kan gjøre. Og gjør sier gjøre dette. Skriv ut denne ut. Så gå videre og få n-- få en int og lagre den i N, og fortsette å gjøre dette igjen og igjen og igjen så lenge som n er mindre enn én. 

Så n kommer til å være mindre enn én bare hvis mennesket er ikke samarbeider. Hvis han eller hun er å skrive i 0 eller -1 eller -50, denne sløyfen kommer til å holde utførende igjen og igjen. Og til slutt merke til, jeg bare returnere verdien. Så nå har vi en funksjon som ville har vært fint hvis CS50 ville gjennomføre i CS50.h og CS50.c for deg, men her kan vi nå implementere dette selv. 

Men to kommentarer på noen viktige detaljer. One-- hvorfor gjorde jeg erklære int n, tror du, på linje 29. istedenfor bare å gjøre dette her, som er mer i samsvar med hva vi gjorde i forrige uke? Yeah? En god tanke. Så hvis vi skulle sette det her, er det som om vi holde erklære det igjen og igjen. Det i seg selv er ikke er problematisk, per se, fordi vi bare trenger verdien en gang og deretter vi kommer til å få en ny en uansett. Men en god tanke. Yeah? 

Lukk. Så fordi jeg har erklært n på linje 29 utenfor sløyfen, det er tilgjengelig i hele Hele denne funksjonen. Ikke de andre funksjoner fordi n er fortsatt inne i disse krøllete bukseseler her. So-- sikker. 

Nettopp. Så dette er enda mer til punktet. Dersom vi i stedet erklærte n her på linje 32, det er problematisk fordi gjetning hvor ellers jeg trenger å få tilgang til det? På ledningen 34, og den enkel tommelfingerregel er at du bare kan bruke en variabel innsiden av de nyeste klammeparentes der du erklærte den. 

Dessverre, linje 34 er en linje for sent fordi jeg har allerede stengt curly brace on line 33 som tilsvarer klammeparentes på linje 30. Og så dette er en måte å si at denne variabelen int er scoped, så å si, å bare inne av de klammeparentes. Det betyr bare eksisterer utenfor dem. 

Så ja, hvis jeg gjør dette galt, la meg lagre koden som det er-- feil skrevet. La meg gå videre og gjør funksjon-en, og notice-- feil. Bruk av svart identifikator n på linje 35, som er rett her. Og hvis vi bla opp ytterligere, annen. Bruk av svart identifikator n on line 34. 

Så kompilatoren, Clang, legger merke til at det bare ikke eksisterer selv om klart det er det visuelt. Så en enkel fiks er å erklære den der. 

Nå la meg bla til toppen av filen. Hva hopper ut på deg som blir litt annerledes fra ting vi så på i forrige uke? Ikke bare har jeg navn, ikke bare gjøre Jeg har noen skarpe inkluderer opp toppen, Jeg har noe jeg er ringer en prototype. Nå som ser fryktelig likt det som vi nettopp så et øyeblikk siden on line 27. 

Så la oss slutte fra en annen feilmelding hvorfor jeg har gjort dette. La meg gå videre og slette disse linjene der. Og så vi vet ingenting om prototype. Remake denne filen. Gjør funksjon en. Og nå, faen, fire feil. La oss bla opp til den første. 

Implisitt erklæring funksjon få positiv int er ugyldig i C99. C99 betyr bare 1999 versjon av språket C, som er det vi faktisk bruker. Så hva betyr dette? Vel C-- og mer spesifikt C compilers-- er ganske dumme programmer. De bare vet hva du har fortalte dem, og det er faktisk tematisk fra forrige uke. 

Problemet er at hvis jeg går om å implementere navn her oppe, og jeg kaller en funksjon som heter GetPositiveInt her på linje 20, som funksjon teknisk ikke eksistere helt til kompilatoren ser line 27. Dessverre er kompilatoren gjøre ting toppen, ned, venstre, høyre, så fordi det ikke har sett den gjennomføring av GetPositiveInt, men det ser du prøver å bruke den opp her, det bare kommer til å bail-- kjefte på du med en feil Message-- kanskje kryptisk, og ikke egentlig kompilere filen. 

Så en såkalt prototype opp her er riktignok overflødig. Bokstavelig talt, gikk jeg ned her, og jeg kopierte og limt dette, og jeg satte den opp her. Void ville være mer riktig, så vi får bokstavelig talt kopiere og lime det denne gangen. Jeg bokstavelig talt kopiert og limt den. Egentlig bare som som en brød smule. 

Et lite hint til kompilatoren. Jeg vet ikke hva dette betyr ennå, men jeg lover deg at det vil eksistere etter hvert. Og det er derfor dette line-- i etter 16-- slutter med et semikolon. Det er overflødig ved design. Ja? 

Hvis du ikke knytte biblioteket å the-- oh, godt spørsmål. Sharp inkluderer header-fil inneslutninger. Trenger du å be-- burde nesten alltid være på toppen av filen for en similar-- for nøyaktig samme grunn, ja. Fordi i standard io.h er bokstavelig talt en linje som dette, men med ordet printf, og med sine argumenter og sin returtype. Og så ved å gjøre skarpe inkluderer opp her, hva du er bokstavelig talt gjør er å kopiere og lime innholdet av noen andre skrev opp toppen. Dermed cluing koden din inn til At eksisterer disse funksjonene. Yeah? 

Absolutt. Så en veldig smart og riktig løsning vil være, vet du hva? Jeg vet ikke hva en prototype er, men jeg vet hvis jeg forstår at C er bare dum og rethinks topp til bunn. Vel la oss gi den det den vil ha. La oss kutte den koden, lim den opp toppen, og nå skyver hoved ned nedenfor. Dette også ville løse problemet. 

Men du kan veldig lett komme opp med et scenario der en trenger å ringe B, og kanskje B samtaler tilbake til A. Dette er noe som kalles rekursjon, og vi vil komme tilbake til det. Og det kan eller ikke kan være en god ting, men du kan definitivt bryte denne løsningen. 

Og dessuten ville jeg hevder stilistisk, spesielt når programmene dine blir dette lenge, og dette lenge, det er bare super praktisk å sette hoved øverst fordi det er tingen mest programmerere kommer til å bry seg om. Og så det er litt renere, uten tvil, å gjøre det på den måten Jeg opprinnelig gjorde det med en prototype selv selv om det ser litt overflødig ved første øyekast. Yeah? Beklager, du kan si det høyere? 

Hvis du bytter de stedene i implementering og prototypen? Så det er et godt spørsmål. Hvis du re-erklære dette ned her, la oss se hva som skjer. Så hvis jeg legger dette ned her, du sier. Oh, beklager. Louder? Enda høyere. Oh, godt spørsmål. Ville det ugyldig funksjon? Du vet, etter alle disse årene, jeg har aldri satt en prototype etterpå. Så la oss gjøre gjøre funksjons 1 etter å gjøre det. 

[Mumler] DAVID J. MALAN: Oh, vent. Vi har fortsatt å sette alt opp toppen. Så la oss gjøre dette opp her, hvis jeg er forstå riktig på spørsmålet ditt. Jeg setter alt, inkludert prototypen ovenfor hoved, men jeg setter prototypen under gjennomføringen. 

Så hvis jeg gjør ett, jeg får tilbake en error-- ubrukt variabel n. Å, det. Takk. La oss se, får vi kvitt dette. Det er en annen bug, så la oss se bort fra det. La oss veldig raskt remake dette. 

OK, så data argument ikke brukt av format String n-- oh, er fordi at Jeg endret til disse her. Greit, vi vet hva svaret kommer til-- all right, here we go. Ah, takk for det positive. Greit, vil jeg fikse denne koden after-- ignorere denne feilen siden dette var-- det fungerer er svaret. 

Slik at den ikke overskrive hva du nettopp har gjort. Jeg mistenker at kompilatoren er skrevet på en slik måte at det er ignorerer din prototype fordi kroppen, så å si, av funksjonen allerede implementert høyere opp. Jeg måtte faktisk ta kontakt håndboken for kompilatoren å forstå hvis det er noen andre implikasjon, men ved første øyekast bare ved å prøve og eksperimentere, det synes å være upåvirket. Godt spørsmål. 

Så la oss videre nå, flytting bort fra bivirkninger som er funksjoner som gjør noe sånt visuelt på skjermen med printf, men ikke returnere en verdi. Og funksjoner som har retur verdier som vi bare så noen av. Vi så allerede denne oppfatningen av omfang, og vi vil se dette igjen og igjen. Men for nå, igjen, bruke tommelfingerregelen at en variabel kan bare benyttes innsiden av mest nylig åpnet og lukkede klammeparentes som vi så i det aktuelle eksempelet. 

Og som du påpekte, det er en ability-- du kan løse noen av disse problemene ved å sette en variabel globalt på toppen av en fil. Men i nesten alle tilfeller vi ville rynke på det, og faktisk ikke engang gå inn som løsning for nå. Så for nå, er det takeaway som variabler har denne oppfatningen av omfanget. 

Men la oss nå se på en annen tørr måte å faktisk ser på noen ganske interessant gjennomføring detaljer. Hvordan vi kan representere informasjon. Og vi allerede sett på dette i den første uken av klassen. Ser på binærfiler, og påminner oss av desimal. 

Men husker fra forrige uke at C har ulike datatyper og bunter mer, men de mest nyttige seg for nå kan være disse. En røye, eller tegn, noe som skjer å være en byte, eller åtte biter totalt. Og det er å si at størrelsen av en char er bare en byte. En byte er åtte biter, slik dette betyr at vi kan representere hvor mange tegn. Hvor mange bokstaver eller symbolene på tastaturet Hvis vi har en byte eller åtte biter. Tenk tilbake til uke null. Hvis du har åtte biter, hvor mange totale verdiene kan du representerer med mønstre av nuller og enere? One-- mer enn det. Så totalt 256 hvis du begynner å telle fra null. Så hvis du har åtte bits-- så hvis vi hadde våre binære pærer opp her igjen, vi kunne slå av disse lyspærer på og av i hvilken som helst av 256 unike mønstre. 

Nå er dette en litt problematisk. Ikke så mye for engelsk og romanske språk, men sikkert når du introdusere, for f eks asiatiske språk, som har langt flere symboler enn som 26 bokstavene i alfabetet. Vi har faktisk kanskje trenger mer enn én byte. Og heldigvis i De siste årene har samfunnet vedtatt andre standarder som bruker mer enn én byte per lading. 

Men for nå i C, standard er bare en byte eller åtte bits. Et heltall, i mellomtiden, er fire byte, også kjent som 32 biter. Hvilket betyr hva som er størst mulig nummer vi kan representere med en int tilsynelatende? Med en milliard. Så det er fire milliarder gi eller ta. 2 til 32th makt, hvis vi anta ingen negative tall og bare bruke alle positive tall, er det fire milliarder gi eller ta muligheter. En flottør, i mellomtiden, er en annen type av datatype i C. Det er fortsatt en del, men det er et reelt tall. Noe med et desimaltegn. Og det viser seg at C bruker også fire bytes å representere flytverdier. 

Dessverre hvor mange flytende punkt verdier er det i verden? Hvor mange reelle tall er det? Det er en uendelig nummer, og for den saks skyld det er et uendelig antall heltall. Så vi er allerede slags grave oss et hull her. Der tilsynelatende i computers-- på minst programmer skrevet i C på dem-- bare kan telle så høyt som fire milliarder gi eller ta, og flytende punkt verdier kan bare tilsynelatende har en viss begrenset mengde av presisjon. Bare så mange sifre etter deres desimaltegn. 

Fordi, selvfølgelig, dersom du bare har 32 bits, Jeg vet ikke hvordan vi skal gå om som representerer reell numbers-- trolig med forskjellige typer mønstre. Men det er sikkert en endelig Antallet slike mønstre, så også her, er dette problematisk. 

Nå kan vi unngå problemet litt. Hvis du ikke bruker en dupp, du kan bruke en dobbel i C, som gir deg åtte bytes, som er måten flere mulige mønstre av nuller og enere. Men det er fortsatt begrenset, som kommer å være problematisk hvis du skriver programvare for grafikk eller for fancy matematiske formler. Så du kan faktisk ønsker å telle opp større enn. En lang long-- dumt named-- er også åtte byte, eller 64 bits, og dette er dobbelt så lang som en int, og det er for en lang heltallsverdi. 

Fun fact-- hvis en int er fire byte, hvor lenge er en lang i C typisk? Også fire bytes, men en lang lang er åtte byte, og dette er historiske årsaker. 

Men takeaway nå er bare at data har å være representert i en computer-- som er en fysisk enhet med strøm, det er generelt kjøre disse nuller og ones-- med begrensede mengder av presisjon. Så hva er problemet da? 

Vel det er et problem av heltall overløp. Ikke bare i C, men i datamaskiner generelt. For eksempel, hvis denne er en byte verdt et bit-- så hvis dette er åtte bit-- alle som er nummer én. Hvilket nummer er dette representerer hvis vi antar det er alle positive verdier i binær? 

255, og det er ikke 256, fordi null er det laveste antallet. Så 255 er den høyeste en, men problemet er anta at jeg ønsket å øke denne variabelen som bruker åtte biter totalt hvis jeg ønsker å øke den. 

Vel så snart jeg legger til en en til alle disse seg, du kan kanskje forestille visually-- bare som å bære den ene ved hjelp decimals-- noe som kommer til å strømme til venstre. Og ja, hvis jeg legge til nummeret en til dette, hva som skjer i binær er at det renner tilbake til null. 

Så hvis du bare use-- ikke en int, men en enkelt byte for å telle heltall i et program, ved default-- så snart du kommer til 250, 251, 252, 253, 254, 255-- 0 kommer etter 255, som sannsynligvis ikke hva en bruker kommer til å forvente. 

Nå i mellomtiden i flyttall verden, du har også et lignende problem. Ikke så mye med den største number-- selv om det er fortsatt et problem. Men med mengden av presisjon at du kan representere. Så la oss ta en titt på dette eksempelet her også fra dagens kilde code-- flyte-0.c. 

Og legg merke til det er en super enkelt program som bør tydeligvis skrive ut hvilken verdi? Hva satse du dette kommer til å skrive ut selv om det er litt av ny syntaks her? Så forhåpentligvis 0,1. Så tilsvarer en tiendedel fordi jeg gjør en dividert med 10. Jeg lagrer svaret i en variabel kalt f. At variabelen er av typen float, som er et nøkkelord jeg bare foreslått eksisterte. 

Vi har ikke sett dette før, men dette er slags en ryddig måte i printf å angi hvor mange sifre du ønsker å se etter et desimaltegn. Så denne notasjonen betyr bare at her er en plassholder. Det er for en flyttall verdi, og oh, forresten, viser den med desimaltegnet med ett tall etter desimaltegnet. Så det er antall signifikante sifre, så å si, som du kanskje ønsker. 

Så la meg gå videre og gjøre gjøre float-0, ./float-0, og tilsynelatende en delt på 10 er 0,0. Nå hvorfor er dette? 

Vel igjen, er datamaskinen tar meg bokstavelig talt, og jeg har skrevet en og jeg skrevet 10, og ta en gjetning på hva er det antatt datatypen for de to verdier? En int, er det teknisk sett noe litt annerledes. Det er vanligvis en lang, men det er til slutt en integrert verdi. Ikke et flyttall. 

Som er å si at hvis dette er en int, og dette er en int, Problemet er at datamaskinen har ikke evnen til og med lagre som desimaltegn. Så når du gjør en delt av 10 bruker heltall til både telleren og evner, bør svaret være 0,1. Men computer-- fordi de er integers-- vet ikke hva jeg skal gjøre med 0,1. 

Så hva er det tydelig gjør? Det er bare å kaste det bort, og det jeg ser i siste instans er 0,0 bare fordi jeg insisterte på at printf vise meg én desimal. Men problemet er at hvis du dele et heltall med et heltall, du vil get-- per definisjon av C-- et heltall. Og det er ikke til å gjøre noe fint og praktisk som runde det opp til nærmeste en opp eller ned. Det kommer til å avkorte alt etter desimal. 

Så bare intuitivt, hva er trolig en løsning? Hva er den enkleste fix her? Yeah? Nettopp. Hvorfor ikke vi bare behandle disse som flyt verdier effektivt gjøre dem til flyter eller dobles. Og nå hvis jeg gjør flyter-0, eller om jeg kompilere flyter-en, som er identisk hva var bare foreslått. Og nå gjør jeg flyter-0, nå får jeg min 0,1. 

Nå er dette fantastisk. Men nå skal jeg gjøre noe litt annerledes. Jeg er nysgjerrig på å se hva som er virkelig skjer under panseret, og jeg kommer til å skrive ut dette ut til 28 desimaler. Jeg ønsker å virkelig se 0.1000-- en infinite-- [Uhørbart] 27 nuller etter det 0,1. 

Vel la oss se om det er hva jeg faktisk får. Gjør flyter-0 samme filen. ./floats-0. La oss zoome inn på den dramatiske svaret. Hele denne tiden, du har vært å tenke 1 dividert med 10 er 10%, eller 0,1. Det er ikke. I det minste så langt som den datamaskinens bekymret. 

Nå why-- OK, det er komplett lie 1 dividert med 10 er 0,1. Men why-- som ikke er takeaway i dag. Så hvorfor tror datamaskinen, i motsetning til alle oss i rommet, at 1 dividert med 10 er faktisk at gal verdi? Hva er datamaskinen gjør tilsynelatende? Hva er det? 

Det er ikke overløp, per se. Overløp er typisk når du vikle rundt en verdi. Det er denne utgaven av unøyaktighet i et flyttall der du bare har 32 eller kanskje til og med 64 bit. Men hvis det er en uendelig antall virke numbers-- tall med desimaler og tall thereafter-- sikkert du kan ikke representere dem alle. Slik at maskinen har gitt oss det nærmeste treffet til verdien det kan representere ved hjelp av at mange biter til verdien jeg faktisk ønsker, som er 0,1. 

Dessverre, hvis du begynne å gjøre matte, eller du starte involverer slike flytende punktverdier i viktig programs-- økonomisk programvare, militære software-- noe hvor oppfatningen er sannsynligvis ganske viktig. Og du begynner å legge tall som dette, og start kjører den programvaren med virkelig store innganger eller for mange timer eller mange dager eller mange år, disse bitte små feil sikkert kan legge opp over tid. 

Nå som en side, hvis du noen gang sett Superman 3 eller Office Space og du kanskje husker hvordan disse gutta stjal en masse penger fra sin datamaskin ved å bruke flytende punkt verdier og legge opp litt rester, forhåpentligvis den filmen nå gjør mer fornuftig. Dette er hva de var henviser til i den filmen. Det faktum at de fleste selskaper ville ikke se etter et visst antall desimaler, men de er fraksjoner av cent. Så du begynner å legge dem opp, du begynner å tjene mye penger på bankkontoen din. Så det er Office Space forklart. 

Nå dessverre utover Office Space, der er noen legitimt problema og vesentlige virkninger av slike underliggende design beslutninger, og faktisk en av grunnene vi bruker C i løpet er slik at du virkelig har denne bakken opp forståelse av hvordan datamaskiner fungerer, hvordan programvaren fungerer, og ikke ta noe for gitt. 

Og ja dessverre, selv med som grunnleggende forståelse, vi mennesker gjør feil. Og det jeg tenkte jeg skulle dele er dette åtte minutters video her tatt fra en Modern Marvels episode, som er en pedagogisk show på hvordan ting fungerer som maler to bilder av når en feil bruk og forståelse av flyt verdier førte til noen vesentlig uheldige resultater. La oss ta en titt. [VIDEOAVSPILLING] -Vi nå tilbake til "Engineering Katastrofer "på Modern Marvels. Datamaskiner. Vi har alle kommet til å akseptere ofte frustrerende problemer som fikk med dem-- bugs, virus, og programvare glitches-- for små priser å betale for enkelhets skyld. Men i high tech og høy hastighet militære og romprogram applikasjoner, det minste problemet kan foredles til katastrofe. 

Den 4. juni 1996 forskere forberedt å lansere en ubemannet Ariane 5-raketten. Det var bærer vitenskapelig satellitter designet å etablere nøyaktig hvordan Jordens magnetfelt samhandler med solvinder. Raketten ble bygget for European Space Agency, og tok av fra sitt anlegg på kysten av Fransk Guyana. 

-At Rundt 37 sekunder inn flyturen, de første lagt merke til noe gikk galt. At dysene ble sving på en måte de egentlig ikke burde. Rundt 40 sekunder inn i flyet, klart kjøretøyet var i trøbbel, og det er da de gjorde beslutningen om å ødelegge det. Utvalget verneleder, med enorm guts, trykket på knappen og blåste opp raketten før det kunne bli en fare for offentlig sikkerhet. 

-Dette Var jomfru voyage av Ariane 5, og dens ødeleggelse tok sted på grunn av feilen innebygd i raketten programvare. -The Problem på Ariane var at det var et tall som kreves 64 bits til å uttrykke, og de ønsket å konvertere det til en 16-bits nummer. De antok at antall ble aldri kommer til å bli veldig stor. At de fleste av disse tallene i 64-biters tall var nuller. De var galt. 

-The Manglende evne til en program for å godta den type tall som genereres av en annen var i roten av svikt. Programvareutvikling hadde blitt en svært kostbare delen av ny teknologi. Ariane 4 raketten hadde vært svært vellykket. Så mye av den programvare som er opprettet for det ble også brukt i Ariane 5. 

-The Grunnleggende problem var at Ariane 5. Ble faster-- akselerert raskere, og programvaren hadde ikke tatt høyde for det. 

-The Ødeleggelse av raketten var en stor økonomisk katastrofe. Alle på grunn av en liten programvarefeil. Men dette var ikke den første time data konverteringsproblemer hadde plaget moderne rakett-teknologi. 

-I 1991 med starten av den første Gulf-krigen, Patriot rakett opplevd en lignende form av et antall konvertering problem. Og som et resultat 28 people-- 28 Amerikanske soldiers-- ble drept, og om lag hundre andre såret. Når Patriot, som skulle å beskytte mot innkommende scuds, ikke klarte å fyre av en rakett. 

-Når Irak invaderte Kuwait, og Amerika lansert Desert Storm i tidlig 1991, Patriot missilbatterier ble utplassert å beskytte Saudi Arabia og Israel fra irakiske Scud rakettangrep. The Patriot er et amerikansk medium-range overflate-til-luft-systemet produsert av Raytheon selskapet. 

-The Størrelsen på Patriot Interceptor itself-- det handler om lag 20 meter lang, og den veier rundt 2000 pounds. Og det bærer et stridshode på ca, Jeg tror det er omlag 150 pounds. Og stridshodet i seg selv en høy eksplosiv, som har fragmenter rundt ham. Så casing av stridshodet er laget for å fungere som en buckshot. 

-The Missiler er gjennomført fire per container, og transporteres med en semitrailer. 

-the Patriot anti-missilsystem går tilbake minst 20 år nå. Det ble opprinnelig utviklet som en luftvernrakett å skyte ned fiendtlige fly. I den første Golfkrigen da at krigen kom, Hæren ønsket å bruke den til skyte ned scuds, ikke fly. Den irakiske Air Force var ikke så mye av et problem, men hæren var bekymret scuds. Og så de prøvde å oppgradere Patriot. 

-Intercepting En fiende missil reiser på Mach 5 skulle være utfordrende nok. Men når Patriot ble styrtet inn i tjeneste, Hæren var ikke klar over en irakisk modifikasjon som gjort sine scuds nesten umulig å den. 

Hva skjedde er de scuds at skulle komme inn var ustabil. De var ustø. Bakgrunnen for dette var de Iraqis-- for å få 600 kilometer ut av en 300 kilometer rekkevidde missile-- tok vekten av frontstridshode, og gjort stridshodet lysere. Så nå patrioten er å prøve å komme ved Scud, og det meste av tid-- det overveldende flertallet av tid-- det ville bare fly av Scud. 

-Når Patriot systemoperatører innså Patriot savnet sitt mål, de detonerte Patriot stridshode å unngå mulige tap hvis det fikk lov til å falle til bakken. 

-Det Var hva folk flest så så store ildkuler på himmelen, og misforstått som avskjærer av Scud-stridshoder. 

-Selv I nattehimmelen, Patriots viste seg å være vellykket ødelegge Scuds, på Dhahran det kunne være ingen feil om ytelsen. Det patriot radar system mistet oversikten over innkommende Scud og aldri lansert på grunn til en programvarefeil. 

Det var israelerne som først oppdaget at jo lenger systemet var på, jo større tidsavviket ble. På grunn av en klokke innebygd i systemets datamaskin. 

-Om To uker før tragedien i Dhahran, israelerne rapportert til Forsvarsdepartementet at systemet var å miste tid. Etter ca åtte timer av å kjøre, de la merke til at systemets bli merkbart mindre nøyaktig. Forsvarsdepartementet svarte med fortelle alle Patriot batterier å ikke la systemene i lang tid. De sa aldri hva en lang tid var. 8 timer, 10 timer, tusen timer. Ingen visste. 

-The Patriot-batteri stasjonert i brakken på Dhahran og dens feil internt klokke hadde vært på over 100 timer på natten av 25 februar. 

-Det spores tid med en nøyaktighet av omtrent en tiendedel av et sekund. Nå er en tidel av et sekund er et interessant tall fordi det ikke kan uttrykkes i binær nøyaktig, som betyr det ikke kan uttrykkes nøyaktig i enhver moderne digital datamaskin. Det er vanskelig å tro, men bruke dette som et eksempel. 

La oss ta nummer én tredjedel. En tredjedel kan ikke være uttrykt i desimal nøyaktig. En tredjedel er 0.333 pågått i det uendelige. Det er ingen måte å gjøre det med absolutte nøyaktigheten i en desimal. Det er akkurat den type problem som skjedde i Patriot. Jo lenger systemet løp, den verre tiden feilen ble. 

-Etter 100 timers drift, feil i tiden var bare om lag en tredel sekund. Men i form av rettet mot en missil reiser på Mach 5, det resulterte i en sporings feil på over 600 meter. Det ville være en fatal feil for soldatene på Dhahran. 

Hva skjedde er en Scud lanseringen var oppdages ved tidlig varsling satellitter, og de visste en Scud kom i deres generelle retning. De visste ikke hvor det kom. Det var nå opp til radaren komponent av Patriot-systemet forsvare Dhahran å finne og holde spor i det innkommende fienden missilet. 

-The Radar var veldig smart. Det ville faktisk spore posisjonen av Scud og deretter forutsi hvor det sannsynligvis ville være neste gang radar sendte en puls ut. Som ble kalt området gate. 

-Da Når Patriot bestemmer nok tid har vedtatt å gå tilbake og sjekke neste plassering for dette oppdagede objektet det går tilbake. Så når det gikk tilbake til feil sted, så ser det ikke noe objekt. Og den bestemmer seg for at det var ingen objekt. At det var en falsk deteksjon og det faller sporet. 

-The Innkommende Scud forsvant fra radarskjermen, og sekunder senere, det slengte inn i brakkene. The Scud drepte 28. Det ble den siste sparken under den første Golfkrigen. Tragisk, den oppdaterte programvaren kom ved daggry på den påfølgende dagen. Programvaren feil hadde blitt fikset, lukking ett kapittel i den urolige historien om Patriot rakett. 

[END VIDEOAVSPILLING] 

DAVID J. MALAN: Det er det for CS50. Vi vil se deg på onsdag. 

[Musikk spilles]