Hjemmeside
Hjemmeside
29.04.2006
Har jobbet en god del med rapporten i det siste. Den har vokst seg til 33 sider med innhold. Ellers er implementasjonen av Sblock-matrisen så godt som ferdig nå. Det som mangler er mulighet for styring. Jeg har lyst til å la en av de innebygde mikrokontrollerene gjøre dette, så får se hva jeg får til de neste halvannen månedene. Ellers trenger jeg en måte å kommunisere med FPGA'en over PCI-bussen. Tror jeg kan overlate dette delvis til mikrokontrolleren også, men vi får se. Det er igrunn de to utfordringene som står igjen i tillegg til å skrive ferdig rapporten.
05.04.2006
En del av tiden siden sist har gått med på å fikse på implementasjonen. Passe på at alt fungerer som det skal osv. Ellers gikk maskinen min istykker for et par uker siden, noe som satte en stopper for videre utvikling av implementasjonen. Men, det var bra for rapport-skrivingen min. Jeg er så godt som ferdig med bakgrunnsmaterialet, mangler bare litt informasjon om tidligere arbeider. Jeg har også skrevet en del om Sblocker og hvordan implementasjonen min fungerer. Det gjenstår en del, men føler jeg har god kontroll over den delen nå.
07.03.2006
Mwohaha, jeg har skapt liv! Nå har jeg akkurat klart å lage en "organisme" med 2x2 celler. Og den oppførte seg akkurat som jeg hadde planlagt, sikkert fått god oppdragelse. :) Regelsettet mitt, eller genomet om du vil, bestod av en to regler hvor bare den ene ble brukt. Denne regelen sa at hvis alle naboene og cellen selv hadde verdien '0', så skal cellen selv få verdien '1'. Hvis cellen selv eller minst en av naboene har verdien '1', så skal cellen få verdien '0'. Jeg satte alle cellene til denne celletypen og ga dem verdien 0. Dette fører til at alle cellene veksler mellom '0' og '1' hver klokke som vist i figuren under. Denne type oppførsel hvor cellen oppdaterer seg i forhold til naboene kalles ofte en Cellulær Automat.
06.03.2006
Har vært slapp på blogginga de siste dagene. Nå begynner implementasjonen virkelig å ta form. Jeg har en helt fungerende Sblock. Nå gjenstår det å lage en slags kontoll på denne og sette mange inn i en matrise. Det er nok en del småplukking igjen, men jeg er optimistisk. Slik det ser ut nå vil det bli plass til en 22x22 matrise. Dette tallet kommer sannsynligvis til å minke litt, men det ser fornuftig ut. Skal regne litt mer på det i morgen for å vise veilederen min, så er blir det oppdateringer! :) Ellers leste jeg et par spennende artikler idag. En om noen som har laget noe lignende det jeg lager. En av forskjellene er at de faktisk hadde laget ASIC'er, dvs egne brikker, som utgjorde cellematrisen. Leste også en artikkel som tok for seg hvordan adaptiv maskinvare kan brukes i roboter i verdensrommet. Ganske smart, siden det både er vanskelig å fjernstyre (pga forsinkelse og signal) og reparere disse.
20.02.2006
Etter en lite produktiv helg er jeg igang igjen. Har laget noen nye figurer siden sist. Først en overordnet figur som viser hvordan en Sblock er koblet sammen med resten av matrisen, den sentrale kontrolleren og reset/klokkesignalene:
I tillegg har jeg laget en figur over hvordan Sblocken er organisert internt. State LUT er det berømte skiftregisteret som holder rede på tilstanden til Sblocken. Development unit startes med devel_enable signalet. Da går den gjennom alle reglene i Rule store (som sjekkes i Rule checker). Hvis en av reglene slår til blir ny konfigurasjon klokket inn i State LUT. Dette tar 32 klokkesykler (vurderer å få dette til på 16, men det krever mer maskinvare). I tillegg kan regelen føre til at en ny state blir satt.
17.02.2006
Idag har jeg rettet opp rapporten etter det jeg fikk som tilbakemelding på forrige veiledningsmøte. Har også lagt til litt mer tekst og en figur av hvordan FPGAen jeg skal bruke er bygd opp. Den flotte figuren kan alle som leser den flotte bloggen min også få se:
16.02.2006
Det skjer stadig ting i prosjektet mitt. Det går ikke så utrolig fort, men føler at jeg kommer sakte men sikkert forover. Til nå har jeg klart å lage en "celle" som har en type (lagret i det berømte shift-registeret) og en verdi. I tillegg klarer denne cellen nå å sjekke om en regel stemmer med verdiene og typene til nabocellene og oppdatere sin egen type (dvs. omkonfigurere shiftregisterene). Cellen har pr. idag 4 forskjellige tilstander: Idle, state-steps, development og configuration. I idle-tilstanden skal ingenting skje. I state-steps skal kun verdien til cellen oppdateres i henhold til hvilken type den er. Dette fungerer. I development-tilstanden skal cellen oppdatere sjekke sin og naboenes type og tilstand med et regelsett. Selve sjekken fungerer, men regelsett-lagringen og gjennomgangen av dette mangler. I configuration-tilstanden konfigureres Shift-registrene slik at cellen får en ny celle-type. Under ser dere et bilde av hvordan det ser ut når jeg tester implementasjonen.
11.02.2006
Har nettopp hatt et lite gjennombrudd. Skjønte hvordan en "16-Bit Shift Register Look-Up-Table (LUT) with Clock Enable" fungerer. Dette kommer til å bli en ganske sentral komponent i cellen, så det er greit å skjønne nøyaktig hvordan den fungerer. Denne komponenten gjør det mulig for cellen å sjekke hva slags verdi nabocellen har med en oppslagstabell som sier hva den nye verdien den skal sende ut selv er.
09.02.2006
De siste ukene har jeg drevet mest med lesing av artikler og å sette meg inn i tidligere arbeid. I tillegg har jeg kjørt gjennom en tutorial fra Xilinx om hvordan man bruker verktøyet deres for å skrive VHDL. VHDL er språket jeg bruker for å programmere FPGA'en. Idag har jeg jobbet med å få til mitt eget design i VHDL. Jeg har laget en enkel entitet som tar inn 2 bit og gir tilbake OR verdien av disse. Det simulerte fint, og syntetiserer også nå (det vil si at det blir oversatt til maskinvarekomponenter). Den logiske kretsen kan du se bilde av under. Venstresiden er input-verdiene (clk er klokka, input1 og input2 er en eller annen verdi som kommer inn og Vcc er strøm). På høyresiden ser man at verdien som har blitt OR'et kommer ut.
09.02.2006
Da er jeg igang med diplombloggen også. Oppgaven min heter "A True Parallell Approach to Cellular Artificial Development in Hardware". Kort fortalt går det ut på å lage en celle som kan utvikle seg og ha en eller annen oppførsel. Denne "cellen" lever på en databrikke som heter Field Programmable Gate Array (FPGA).
23.02.2006
I dag har jeg snakket med Heri Ramampiaro på IDI. Han gav meg mange gode råd! Jeg skal nå sjekke ut Oslo-Bergen-taggeren som er laget ved UiO. Det er også tydelig at det ikke eksisterer en god analyzer for norsk, foreløpig ;) Porter's algoritme kombinert med snowball's regler for norsk funker sånn passe, men langt i fra bra nok. Planen er nå å implementere Porter, få ut av forskerne ved KTH hva de har gjort, og så lage en egen analyzer som knuser alt annet.
17.02.2006
Siden sist har jeg fått litt mer oversikt over stoffet. Mest av alt har jeg prøvd å finne ut om noen har oppnådd gode resultater tidligere. I 2002 utførte John Arne S. Pedersen et forprosjekt der han implementerte en norsk analyzer. Ved stemming og fjerning av stoppord fikk han bedret recall men redusert precision. Ellers er det en gruppe ved KTH som har publisert bedret precision og recall med respektive 15 og 18%. Precision og recall påvirkes av flere faktorer; hvor 'bøyd' språket er(for engelsk, tysk og slovensk får man bedre resultater jo mer bøyd det er). I tillegg vil lengden på spørringer og dokumentene påvirke resultatene. Forskerne fra stockholm hadde brukt dokumenter med et gjennomsnitt på 181 ord. Etter samtale med veilederen min, Stein Joar Gran, kommer det frem at 181 ord i gjennomsnitt er alt for laft for oppdragsgiveren min InfoFinder. Dokumentlengden er veldig varierende fra kunde til kunde, men rundt 2000 ord i snitt burde ikke være langt fra sannheten.
Selve målet med analyzeren er å redusere indeksstørrelsen. For eksempel ved å ta ordene 'springer' og 'springe' fra kilde dokumentet og så føre opp de som étt ord i indeksen som 'springe', så vil man spare en oppføring i indeksen. Man kunne godt ha ført opp alle ordene i dokumentet i indeksen, men da vil indeksen kreve mer disk-plass og det tar lenger tid å søke opp ordet.
Ulike metoder kan benyttes for å løse denne oppgaven. En lemmatiser eller en tagger utfører en komplett gramatisk/morfologisk analyse og reduserer ord til dets respektive lemma. Dette er svært kostbart! Alternativet er å bruke en stemmer. En stemmer finner et ords stem (ikke samme som lemma). Stemming er et sett med regler for et gitt språk, og kan ikke bevises rent lingvistisk. Ulike algoritmer finnes; Porter 1980 og KSTEM er to eksempler.
------------------------
Precision - antall relevante funnet/totalt antall dokumenter funnet
Recall - antall relevante funnet/totalt antall relevante dokumenter
08.02.2006
Min diplomoppgave har tittelen "Norwegian Analyzer for DotLucene". En analyzer brukes i forbindelse med indeksering av søkbar tekst. Den har to hovedoppgaver; stemming og fjerning av stoppord. Stemming er den vanskeligste delen og betyr kort sagt at man fjerner endelser, slik at om det foretaes et søk på 'connect' skal man få treff både på 'connect' og 'connections'. I de fleste tilfeller kan man bruke et sett av regler for å fjerne endelser. Dersom det forekommer et unntak, f.eks resume/resumption, vil ikke regelsettet fungere. Stoppord er ord med lavt semantiskt innhold. F.eks 'er', 'har' og 'man'. Her er det mange spennende utfordringer å ta tak i. Følg med videre!
08.02.2006
Velkommen til denne kule bloggen! Statusrapporter og andre åpenbaringer kommer til å bli blogget løpende fram mot juli 2006. Da er vi forhåpentligvis er ferdige med våre diplomoppgaver. Jippi!