Advertentie | |
|
03-11-2006, 05:46 | ||
Citaat:
Code:
<syntax> ::= <rule> <followrules> <followrules> ::= <syntax> <followrules> ::= ε <rule> ::= NONTERMINAL DEFINEDAS <production> POINT <production> ::= <term> OR <alternative> <production> ::= <term> <alternative> ::= <production> <term> ::= <factor> <restterm> <term> ::= EMPTY <restterm> ::= <term> <restterm> ::= ε <factor> ::= TERMINAL | NONTERMINAL Dat gebeurt dus tijdens parseRule. Om de een of andere reden denkt de parser dus, dat een <production> niet uit 4 opeenvolgende nonTerminals mag bestaan. Het relevante deel van de grammatica is dus: <production> ::= <term> OR <alternative> <production> ::= <term> <alternative> ::= <production> <term> ::= <factor> <restterm> <term> ::= EMPTY <restterm> ::= <term> <restterm> ::= ε <factor> ::= TERMINAL | NONTERMINAL Hoofdverdachte is parseTerm(). Daar zit namelijk een herhaling in. Dan komt parseProduction(). Daar zit namelijk het "vreemde" stukje grammatica in. De code ziet er daarom anders uit. Tenslotte parseRestTerm(). Daar zit namelijk het andere deel van de herhaling uit parseTerm() in. |
07-11-2006, 01:38 | |||
Citaat:
Citaat:
Gelukkig (Helaas?) duurde het weekend langer omdat ik niet naar huis kon omdat Rotterdam Centraal zo'n beetje dicht was afgelopen zondag. Maar ik had hetzelfde vermoeden al, ja. Hoe bedoel je trouwens "het vreemde stukje grammatica"?
__________________
Bad spelling and grammar make me [sic].
|
07-11-2006, 09:06 | |||
Citaat:
Citaat:
De meeste andere herhalingen hebben we zo uitgeschreven, dat twee alternatieven nooit met eenzelfde symbool beginnen. --- Gevolg is, dat de code van parseProduction() er net iets anders uit zal zien als de code van parseSyntax() of parseTerm() . Soms kun je fouten snel herkennen door een soort "patroonherkenning". Je kijkt dus *eerst* naar dingen die er anders uitzien dan de rest. Vaak kun je dat verschil verklaren. Als je het verschil niet direct kunt verklaren, dan is er wellicht sprake van een fout. Dat is zo'n beetje de eerste stap in het opzoeken van fouten: - Eerst kijk je naar dingen die er vreemd uitzien. - Dan zoek je de andere fouten op. - Tenslotte verwerk je alle warnings. In ons geval zijn er (zo op het oog) 3 plaatsen waar afwijkende patronen kunnen voorkomen: - In de grammatica - In de code - In de uitvoer Voorbeeld: - De productieregels voor <term> en <restterm> zien er net iets anders uit als de productieregels voor <syntax> en <followrules> . Dat kunnen we verklaren, dus het is geen fout in de grammatica. Wel betekent het, dat de programmacode ook iets zal afwijken. En het betekent dat de testsets (en/of de uitkomstvoorspellingen) iets zullen verschillen. Onze reviewers gebruiken deze techniek ook bij het controleren van onze ontwerpdocumenten. Als twee stukken tekst op elkaar lijken maar op een punt verschillen, krijgen we daar doorgaans commentaar op. En dat kan dan tot gevolg hebben, dat we het ontwerp aanpassen. Het kan ook tot gevolg hebben, dat we op die plaats in het ontwerp wat uitleg toevoegen. En soms leggen we het commentaar naast ons neer. Dat kan bijvoorbeeld, indien dat stuk van het document bedoelt is voor technische mensen terwijl de reviewer functioneel of business is. Of omgekeerd. ------------- In de huidige situatie hebben we een goedgekeurde grammatica. Er is een testgeval waarop de parser zich stuk bijt. Daarom heb ik eerst gekeken naar het betreffende stuk in de grammatica. En daar zijn in feite 3 stukjes die om aandacht vragen. Een van die 3 stukjes is <production>. Hierbij is het enige probleem, dat dit stukje grammatica een klein beetje anders is uitgewerkt. De code ziet er dus iets anders uit. Dus dat vertroebelt het globale deel een beetje. Dit hoeft niet fout te zijn, maar: - Het kan zijn dat hierdoor een fout niet opvalt. - Het kan zijn dat hierdoor iets opvalt wat geen fout is. Daarom zul je in de praktijk meestal proberen, tijdens de ontwerpfase zoveel mogelijk op dezelfde manier te doen. - Dat maakt het maken van het ontwerp makkelijker. - Dat maakt het controleren van het ontwerp makkelijker. - Dat maakt de volgende fase makkelijker. - Dat maakt het ontwerpen van de test makkelijker. - Dat maakt het checken van de testuitvoer makkelijker. - Dat maakt het acceptatie-proces makkelijker. Dat verklaart natuurlijk tevens, waarom verschillende delen van de organisatie geneigd zijn mee te werken, als je "achteraf" alsnog een ontwerp wilt aanpassen. Maar vaak houden de kwaliteitsnormen zo'n verbeteringsslag tegen. |
07-11-2006, 12:15 | |
Oh, op die fiets!
Hm, als de code raar is, is het dan niet slimmer om er zoiets als <production> ::= <singleproduction> | <multipleproductions> <multipleproductions> ::= <term> OR <alternative> <singleproduction> ::= <term> van de maken? Zo behoud je de structuur en krijg je geen rare code voor parseProduction(). Of krijg ik nu weer een probleem met de lookahead (aangezien er in de essentie niet écht iets veranderd)? Zou dit makkelijker te coden zijn, of maakt het niet zoveel uit? Nee, volgens mij is dit niet makkelijker. Want hoe ga ik erachter komen welke hij moet parsen? Ik kijk wel na college.
__________________
Bad spelling and grammar make me [sic].
|
07-11-2006, 15:20 | ||
Citaat:
Volgens mij kun je het best wel voor elkaar krijgen met de versie van de grammatica die jij goed hebt laten keuren. De code van de betreffende functie ziet er dan wel iets anders uit. En als je terugkijkt in jouw code, zie je dat de code er inderdaad ietrs anders uit ziet. Nadeel is vooral, dat je *twee* keer moet bedenken hoe je dat programmeers (een keer voor <production>, en een keer voor alle andere plaatsen), en dat je later (nu, dus) *twee* keer moet nadenken of die code wel goed is. Gevolg is dus, dat je voor de huidige fout op *drie* plaatsen begint te zoeken, in plaats van op *twee* plaatsen. Geen grote verschillen. Dus geen goede reden om op dit moment iets aan je specificaties te veranderen ... |
07-11-2006, 17:50 | ||
Nee, je hebt gelijk. Maar het was maar een idee.
Ik heb het even aan mijn docent gevraagd (aangezien het volgende week vrijdag af moet zijn en er nog genoeg moet gebeuren) en hier kwam hij mee: Citaat:
Maar ik kan in ieder geval weer verder. ----- Trouwens, leer je hier zelf ook wat van, of niet?
__________________
Bad spelling and grammar make me [sic].
|
07-11-2006, 20:49 | |
Er zit geen parseEmpty() in mijn parseProduction().
Blijkbaar miste ik ook wat accolades... maar omdat het script er alles doorheen joeg, zag ik geen errors. Het probleem: er was een accolade teveel. Zucht. Anyway, hij parsed. w00t. Hij kan zelfs onze grammatica parsen zonder problemen. Hij kan ook een willekeurig aantal nonterminals parsen. Ik denk nou wel dat ie het doet en dat ie goed is. Even langs de docent om te vragen...
__________________
Bad spelling and grammar make me [sic].
|
08-11-2006, 18:19 | ||
Citaat:
Wat denk jij dat effectiever is? Map of tree?
__________________
Bad spelling and grammar make me [sic].
|
08-11-2006, 22:26 | |
Even denken...
In feite allebei! Voor de boomstructuur heb je geen tree nodig; De boomstructuur bouw je gewoon door de inhoud van je objecten. En je moet op gegeven moment allerlei zaken kunnen opzoeken voor een nonterminal. En opzoeken kan uitstekend met een Map. Daarom zegt jouw docent, dat je bijvoorbeeld een map kunt gebruiken. ------------------- Ik vermoed dat er nog best wel wat werk verricht moet worden, voordat je het programma werkend krijgt. Bedenk bijvoorbeeld dat jouw parseXxx() functies geen resultaat opleveren. Dus je zult een manier moeten verzinnen om de tussenresultaten correct aan elkaar vast te knopen. -------------------- Bedenk bij die interne opslagstructuur het volgende: - Je moet hem kunnen bouwen. - Je moet hem kunnen gebruiken. Je zult hem sowieso moeten gebruiken tijdens het uitvoeren van de algoritmen voor First en Follower. En wellicht ook voor weergave van de ingelezen grammatica (afhankelijk van wat er precies in je opdracht staat. En je zult moeten zorgen dat jouw parser de structuur kan bouwen. |
08-11-2006, 22:36 | ||
Citaat:
- Ik krijg op deze manier een kijkje in wat er momenteel zoal op de opleiding gebeurt. - Er komt van alles weer bovendrijven wat ik 25 jaar geleden heb geleerd. En ik zie nu opeens verbanden met andere zaken. Veelal met zaken die ik pas veel later geleerd heb (vaak in de praktijk). - Ik krijg weer allerlei ideeen over wat je tegenwoordig allemaal met computers kunt doen. Zelfs als je geen Java beschikbaar hebt, is er altijd nog wel Excel aanwezig op de meeste computers, en de ingebouwde VBA is een stuk krachtiger en veelzijdiger dan de meeste mensen denken (Ik heb een paar weken geleden nog een programmaatje in excel vba geschreven dat een aantal doodgewone EBCDIC-bestandjes inleest, en ze combineert tot een enkel bestand met COMP-3 velden. Dat ging wat sneller dan handmatig intikken of laten intikken, en het programma heeft inmiddels zijn nut al bewezen in een andere test waarbij bestanden nodig waren met een andere structuur). - Het is ook weer een goede oefening in uitleggen. En ook in het uitleggen zonder teveel voor te zeggen. |
15-11-2006, 16:33 | |
Even gauw wat van mij laten horen: De opdracht moet morgen af zijn en dat is niet gelukt. Andere vakken waren niet eens zo zeer het probleem; het probleem was dat mijn teamgenoot niet meewerkte waardoor ik alles in mijn eentje deed.
Ik moet hetgene wat ik nu heb inleveren en hopelijk wordt het goedgekeurd omdat ze lagere eisen stellen aan mensen die alleen werken (alle groepen zijn gebaseerd op werken in tweetallen). Ik wil hem nog wel afmaken, maar in een lager tempo en met een lagere prioriteit.
__________________
Bad spelling and grammar make me [sic].
|
Topictools | Zoek in deze topic |
|
|
Soortgelijke topics | ||||
Forum | Topic | Reacties | Laatste bericht | |
Games |
daikatana 64 qghp | 18 | 17-08-2003 16:14 | |
Games |
Golden Sun (probleem) Ieke | 13 | 21-08-2002 18:51 | |
Psychologie |
Emotie versus Rede proycon | 5 | 26-03-2002 12:22 | |
Levensbeschouwing & Filosofie |
evolutie mitsj | 96 | 14-03-2002 20:18 | |
Levensbeschouwing & Filosofie |
Intelligent Design legatus | 28 | 08-02-2002 19:34 | |
Verhalen & Gedichten |
The winter.. striking it's first victim Kazanka | 4 | 07-01-2002 18:19 |