Oud 02-11-2006, 21:36
Rob
Avatar van Rob
Rob is offline
We zijn toch nog niet helemaal klaar met iets. Er zit iets goed verkeerd. Na 2 of 3 nonterminals, gaat ie de volgende nonterminal verkeerd parsen (als een production, geloof ik, niet als een restterm).


Maar dingen werken nog niet helemaal naar behoren met die punt.

<x> ::= <a>.
<y> ::= <b>.
<z> ::= <c>.


Die grammatica kan ie niet parsen. Ik heb de output wat veranderd zodat het duidelijk is welke methode er wordt aangeroepen. Misschien debugged dit wat makkelijker. Hier is de output als ik het bovenstaande wil parsen.

Code:
Tokenkind: 72, token: <x>
  Root symbool geaccepteerd, parseSyntax()
  parseRule()
  Accept een NONTERMINAL

Tokenkind: 70, token: ::=
  Accept een DEFINEDAS

Tokenkind: 72, token: <a>
  parseProduction()
  parseTerm()
  parseFactor()
  accept de (NON)TERMINAL

Tokenkind: 74, token: .
  parseRestTerm()
  Accept een POINT

Tokenkind: 72, token: <y>
  parseFollowRules()
  parseRule()
  Accept een NONTERMINAL

Tokenkind: 70, token: ::=
  Accept een DEFINEDAS

Tokenkind: 72, token: <b>
  parseProduction()
  parseTerm()
  parseFactor()
  accept de (NON)TERMINAL

Tokenkind: 74, token: .
  parseRestTerm()
  Accept een POINT

Tokenkind: 72, token: <z>

parse error in <root> : kind=-1 expected
lookahead '<z>' (kind=72) at 3/1
Exception in thread "main" java.lang.RuntimeException
   at Parser.parseError (Parser.java:52)
   at Parser.accept (Parser.java:74)
   at Parser.parseRoot (Parser.java:101)
   at Main.main (Main.java:14)
Zoals je ziet, gaat ie na de tweede rule op zijn bek omdat ie een EOF verwacht. Dat heeft, geloof ik, te maken met het feit dat followRules() maar een keer wordt aangeroepen en niet zo vaak als het nodig is. Maar hoe ik het fix dat ie een willekeurig aantal rules kan parsen, zie ik zo gauw niet.

Laat maar. Toen ik er net over dacht, schoot het mij te binnen: Na de tweede POINT (en dus de eerste followRules()), is ie klaar met parseSyntax(). Daarna gaat ie door naar parseRoot(). vandaar de crash.
Het enige wat ik hoefde te doen, was het plaatsen van een lookahead direct na POINT en op basis daarvan followRules() aanroepen of niets doen. Alle rules die na de eerste POINT komt, zijn sowieso <followrules>, dus dat lostte dat probleem op.

Ik heb nu eigenlijk het probleem dat als er veel nonterminals, dat ie ineens een punt verwacht.
Echt jammer dat er niet een grammatica is waarmee is alles kan checken...
Ongerelateerd: Ik vind het zo vervelend dat ik wel ergens zie dat er iets mis is, maar niet mijn vinger erop kan leggen, of dat ik wel zie wat er mis is, maar het niet kan coden.
__________________
Bad spelling and grammar make me [sic].

Laatst gewijzigd op 02-11-2006 om 22:17.
Met citaat reageren
Advertentie
Oud 02-11-2006, 22:44
WelVrolijk
WelVrolijk is offline
Citaat:
Ik vind het zo vervelend dat ik wel ergens zie dat er iets mis is, maar niet mijn vinger erop kan leggen, of dat ik wel zie wat er mis is, maar het niet kan coden.
Testen is een vak op zich.

Bij ons op de afdeling lopen ongeveer 4 testers rond die gespecialiseerd zijn in het maken van goede testsets en het checken van testresultaten.
Er is ook een groepje van 2 coordinatoren die bij gevonden defects goed in staat zijn de technische dan wel functionele oorzaak te vinden. Zij zijn ook redelijk goed in het checken van resultaten.
Ik ben meer iemand die goed is in het vinden van technische oorzaken van defects, en in het maken van specifieke testsets.

Van elk van de genoemde vaardigheden heb je iets nodig, om --nadat je geconstateerd hebt dat ergens iets mis is-- precies te kunnen achterhalen wat er mis is.
Met citaat reageren
Oud 03-11-2006, 05:46
WelVrolijk
WelVrolijk is offline
Citaat:
Maar als ik iets als <x> ::= <b><c><d><e>. doe, dan verwacht ie na <d> een punt. Hij's toch nog niet helemaal lekker. Volgens het programma zou de error in parseRule() moeten zitten... Maar na je voorbeeld van daarnet, weet ik dat niet zeker.

Maar het komt er op neer da hij maar 4 nonterminals achter elkaar aankan voor die ermee stopt (dan verwacht ie dus een .).
Onze grammaica zag er als volgt uit:
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
De parser verwacht een POINT.
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.
Met citaat reageren
Oud 07-11-2006, 01:38
Rob
Avatar van Rob
Rob is offline
Citaat:
WelVrolijk schreef op 02-11-2006 @ 22:44 :
Testen is een vak op zich.

Bij ons op de afdeling lopen ongeveer 4 testers rond die gespecialiseerd zijn in het maken van goede testsets en het checken van testresultaten.
Er is ook een groepje van 2 coordinatoren die bij gevonden defects goed in staat zijn de technische dan wel functionele oorzaak te vinden. Zij zijn ook redelijk goed in het checken van resultaten.
Ik ben meer iemand die goed is in het vinden van technische oorzaken van defects, en in het maken van specifieke testsets.

Van elk van de genoemde vaardigheden heb je iets nodig, om --nadat je geconstateerd hebt dat ergens iets mis is-- precies te kunnen achterhalen wat er mis is.
Heh, ja. Vooral het invoeren van alle mogelijke dingen is iets dat ik nog wel eens vergeet in zijn geheel uit te voeren (en dus vergeet ik dan kleine, logische, voordehandliggende dingen).

Citaat:
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.
Ik heb nog niet de tijd genomen er naar te kijken. Even een weekendje zonder parsers, grammatica's e.d. om een frisse blik te krijgen.
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].
Met citaat reageren
Oud 07-11-2006, 09:06
WelVrolijk
WelVrolijk is offline
Citaat:
Rob schreef op 07-11-2006 @ 01:38 :
Hoe bedoel je trouwens "het vreemde stukje grammatica"?
In onze grammatica staat ergens:
Citaat:
<production> ::= <term> OR <alternative>
<production> ::= <term>
Beide alternatieven beginnen met <term> .

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.
Met citaat reageren
Oud 07-11-2006, 12:15
Rob
Avatar van Rob
Rob is offline
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].
Met citaat reageren
Oud 07-11-2006, 15:20
Vrolijk
Citaat:
Rob schreef op 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.
Je kunt beter niet tot in het oneindige bezig blijven met het wijzigen van je specificaties.

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 ...
Met citaat reageren
Oud 07-11-2006, 17:50
Rob
Avatar van Rob
Rob is offline
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:
Dag Robbert,
parseProduction() is fout: als je na parseTerm() geen OR tegenkomt moet je helemaal niets meer doen, maw. dan is de methode afgelopen !!!
De regel <term> ::= EMPTY moet weg uit je grammatica
parseterm bestaat dan uit alleen parsefactor en parserestterm
En in parseRestTerm() moet natuurlijk niet parseFactor(), maar parseTerm() aangeroepen worden.
Weer heel wat te verbeteren dus.
Lekker is dat. Grammatica wijzigen. Het is niet zo groot, maar het gaat er mij om dat ie daar niet eerder mee kwam.

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].
Met citaat reageren
Oud 07-11-2006, 19:52
WelVrolijk
WelVrolijk is offline
Dat vind ik vreemd.

Als je <term> ::= EMPTY weglaat, kun je <x> ::= ε . niet langer verwerken.

---

Die parseEmpty() moet natuurlijk *wel* weg uit je parseProduction() ...
Met citaat reageren
Oud 07-11-2006, 20:49
Rob
Avatar van Rob
Rob is offline
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].
Met citaat reageren
Oud 08-11-2006, 18:19
Rob
Avatar van Rob
Rob is offline
Citaat:
Voor de interne structuur zou ik een map gebruiken met als key de naam van de nonterminal en als value een object van een door jou te schrijven class NonTerminal. In dat object komen dan alle productieregels die er voor deze nonterminal zijn. Dat betekent dat er ook een class ProduktieRegel komt.
Hij heeft nog niet naar de parser gekeken, maar aangezien die wel werkt, zijn er vast alleen nog maar minimale aanpassingen nodig om de rest draaiend te krijgen.

Wat denk jij dat effectiever is? Map of tree?
__________________
Bad spelling and grammar make me [sic].
Met citaat reageren
Oud 08-11-2006, 22:26
WelVrolijk
WelVrolijk is offline
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.
Met citaat reageren
Oud 08-11-2006, 22:36
WelVrolijk
WelVrolijk is offline
Citaat:
Rob schreef op 07-11-2006 @ 17:50 :
Trouwens, leer je hier zelf ook wat van, of niet?
Ja hoor, ik vind het heel leerzaam.

- 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.
Met citaat reageren
Oud 15-11-2006, 16:33
Rob
Avatar van Rob
Rob is offline
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].
Met citaat reageren
Oud 22-01-2007, 21:30
Rob
Avatar van Rob
Rob is offline
Nou, het tentamen heb ik in ieder geval netjes afgerond met een 8.
En de LL(1) checker? Tsja, die zal niet zo snel afkomen en da's wel jammer. Maar het vak heb ik in ieder geval gehaald.
__________________
Bad spelling and grammar make me [sic].
Met citaat reageren
Oud 22-01-2007, 22:31
WelVrolijk
WelVrolijk is offline
Gefeliciteerd!
Met citaat reageren
Advertentie
Reageren

Topictools Zoek in deze topic
Zoek in deze topic:

Geavanceerd zoeken

Regels voor berichten
Je mag geen nieuwe topics starten
Je mag niet reageren op berichten
Je mag geen bijlagen versturen
Je mag niet je berichten bewerken

BB code is Aan
Smileys zijn Aan
[IMG]-code is Aan
HTML-code is Uit

Spring naar

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


Alle tijden zijn GMT +1. Het is nu 16:04.