[Java] Bord van Galton

[egonolieux]

Beste tweakers,

Tegen volgende week moet ik mijn project "Bord van Galton" indienen, maar ik stoot steeds op hetzelfde probleem dat ik maar niet opgelost krijg. Het probleem doet zich voor wanneer de simulatie meer dan 2 maal uitgevoerd moet worden. Als ik bijvoorbeeld een automatische simulatie 1000 keer wil uitvoeren, dan zal mijn programma er maar 2 uitvoeren. Hetzelfde geldt als ik 2 stappen uitvoer bij de stappensimulatie.

Voor het opnieuw uitvoeren van een bepaalde methode gebruikte ik aanvankelijk gewoon een verwijzing naar die methode zelf door "methode()" op het einde te zetten, maar aangezien dit niet echt hoort heb ik deze vervangen door do - while lussen. Aanvankelijk "op de verkeerde manier" werkte het volledig naar behoren, maar sinds ik de do - while lussen geïmplementeerd heb doet bovenstaand probleem zich voor.

Hier is de volledige code:

code:

*snip*

[ Voor 76% gewijzigd door RobIII op 20-11-2011 01:47 ]

[Styxxy]

Prograaming FAQ > Tips bij debuggen

Wat heb je al geprobeerd om het probleem te localiseren?

[egonolieux]

Wel, dat is nu juist het probleem. Ik zie het probleem gewoonweg niet; in mijn ogen is deze code correct.
Let wel op dat het hier niet om een compileerfout gaat, maar om een run-time fout.

[CoolGamer]

Heb je stappen geprobeerd die in de FAQ staan? Zoals door de code lopen met een debugger? Als je dat laatste doet heb je waarschijnlijk de oorzaak zo gevonden.

[Rian]

Volgens mij vergeet je position te resetten in bepaaldBord. Na enkele stappen is position > 7, en dus evalueert geen enkel case statement meer. Als je dat aanpast, komen er wel getallen groter dan 0 of 1 in die verdeling onderaan te staan.

En.. nederlandse code

[ Voor 28% gewijzigd door Rian op 19-11-2011 23:58 ]

[egonolieux]

De FAQ had ik reeds doorlopen voor ik dit topic startte.

Rian schreef op zaterdag 19 november 2011 @ 23:57:
Volgens mij vergeet je position te resetten in bepaaldBord. Na enkele stappen is position > 7, en dus evalueert geen enkel case statement meer. Als je dat aanpast, komen er wel getallen groter dan 0 of 1 in die verdeling onderaan te staan.

En.. nederlandse code

Ik ben ook radicaal tegen Nederlandstalige code, maar het moest nu eenmaal van de docent .
Wat je daar zegt is inderdaad correct, bij het herschrijven van mijn code zoals ik eerder al zei moet ik per ongeluk de regel "position = 1" bij het begin van de "doeSimulatieBerekening" methode verwijderd hebben .
Vandaar dat ik er ook van uit ging dat mijn code werkte.
Afijn, probleem van de baan geholpen zou ik zeggen.

[ Voor 7% gewijzigd door egonolieux op 20-11-2011 00:23 ]

[Styxxy]

egon088 schreef op zaterdag 19 november 2011 @ 23:38:
Wel, dat is nu juist het probleem. Ik zie het probleem gewoonweg niet; in mijn ogen is deze code correct.
Let wel op dat het hier niet om een compileerfout gaat, maar om een run-time fout.

Uiteraard compileert de code (anders zou je ook niet kunnen gaan "debuggen"). Ik raad je aan om de FAQ link dat ik je gegeven heb, eens goed te lezen.

Rian schreef op zaterdag 19 november 2011 @ 23:57:
Volgens mij vergeet je position te resetten in bepaaldBord. ...

"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime."

Zulke zaken zijn gemakkelijk te achterhalen mocht hij gewoon even debuggen. Nu leert hij ook niet echt om fouten te zoeken, maar fixt het probleem en heeft niets geleerd. Laat hem eerst eens spelen met een debugger om te achterhalen wat de fout is (en hey, nu leert hij ook een debugger gebruiken).

egon088 schreef op zondag 20 november 2011 @ 00:19:
De FAQ had ik reeds doorlopen voor ik dit topic startte.

Misschien is het dan verstandig eens wat te verdiepen in debuggen. (Gebruik een debugger of doe het old-school door waarden af te drukken om de state te onderzoeken.)

egon088 schreef op zondag 20 november 2011 @ 00:19:
Wat je daar zegt is inderdaad correct,

En nu heb je het antwoord zonder eigenlijk iets geleerd te hebben. (Zie hierboven.)

[ Voor 21% gewijzigd door Styxxy op 20-11-2011 00:22 ]

[Verwijderd]

Styxxy schreef op zondag 20 november 2011 @ 00:19:
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime."

Dat is toch wel een heel erg slecht idee, alleen maar vis eten

Daarbij kan je bij code zien wat er gebeurd is om die code te bereiken. Als je een vis aan iemand geeft ziet hij dat niet.

[egonolieux]

[...]
Misschien is het dan verstandig eens wat te verdiepen in debuggen. (Gebruik een debugger of doe het old-school door waarden af te drukken om de state te onderzoeken.)

Tot zo ver mijn kennis gaat, ging ik er van uit dat debuggen met javac bedoeld werd.
Ik heb pas sinds 2 maand java en we hebben dit nog niet besproken.

[...]
En nu heb je het antwoord zonder eigenlijk iets geleerd te hebben. (Zie hierboven.)

De code die ontbrak had ik al eerder gebruikt; gewoonweg per ongeluk weggelaten. Ik zou dit niet zozeer "niets bijgeleerd noemen", tenzij je het over debuggen hebt.

[Jegorex]

Java:

            if (chance > 0.50) { // indien het random getal groter is dan 0.50 (50%) wordt de balpositie met 1 verhoogd (naar rechts)
                position++;
            }

Uit de javadoc van Math.random():

Returns a double value with a positive sign, greater than or equal to 0.0 and less than 1.0.

chance > 0.50 is dus niet exact de helft

[egonolieux]

oeps, 0.49 dus

[Jegorex]

egon088 schreef op zondag 20 november 2011 @ 01:06:
oeps, 0.49 dus

Dat klopt ook niet, tenzij je een oneindig aantal 9's gaat toevoegen. (ik weet dat dit niet 100% nauwkeurig is, floats en doubles kunnen rare dingen doen.)
Ik zou die 0.5 gewoon laten staan en een ander teken wijzigen.

[ Voor 14% gewijzigd door Jegorex op 20-11-2011 01:10 ]

[Herko_ter_Horst]

N.m. al gezegd door Jegorex.

[ Voor 135% gewijzigd door Herko_ter_Horst op 20-11-2011 01:17 ]

[Styxxy]

egon088 schreef op zondag 20 november 2011 @ 00:30:
[...]
Tot zo ver mijn kennis gaat, ging ik er van uit dat debuggen met javac bedoeld werd.
Ik heb pas sinds 2 maand java en we hebben dit nog niet besproken.

Je hoeft niet per se een volledige debugger te gebruiken. Je kan ook gewoon waardes afdrukken om te zien wat er aan het gebeuren is.

egon088 schreef op zondag 20 november 2011 @ 00:30:
De code die ontbrak had ik al eerder gebruikt; gewoonweg per ongeluk weggelaten. Ik zou dit niet zozeer "niets bijgeleerd noemen", tenzij je het over debuggen hebt.

Wat heb je geleerd van de quick fix op de code dat je per ongeluk hebt weg gelaten? Inderdaad, ik bedoel dat je niets hebt bijgeleerd (ondertussen misschien wel). Problemen zoeken, vinden en fixen, zal je nog veel doen als je code schrijft. Leren hoe dat je die problemen vindt, is dan ook essentieel.

[RobIII]

Als je code plaatst, plaats dan enkel voor je probleem relevante code. Bijna 200 regels code dumpen en anderen 't probleem laten spotten is not-done hier.

Verwijderd schreef op zondag 20 november 2011 @ 00:29:
[...]

Dat is toch wel een heel erg slecht idee, alleen maar vis eten

Daarbij kan je bij code zien wat er gebeurd is om die code te bereiken. Als je een vis aan iemand geeft ziet hij dat niet.

En bedankt voor deze nuttige bijdrage...

egon088 schreef op zaterdag 19 november 2011 @ 23:38:
Wel, dat is nu juist het probleem. Ik zie het probleem gewoonweg niet; in mijn ogen is deze code correct.
Let wel op dat het hier niet om een compileerfout gaat, maar om een run-time fout.

egon088 schreef op zondag 20 november 2011 @ 00:30:
Tot zo ver mijn kennis gaat, ging ik er van uit dat debuggen met javac bedoeld werd.

Dan heb je de link die geplaatst werd klaarblijkelijk niet gelezen danwel begrepen. Debuggen is een proces. Je bedenkt wat je code zou moeten doen (je verwachtingen) en daarna ga je kijken wat er daadwerkelijk gebeurt (je verwachtingen langs de werkelijkheid leggen). En vervolgens ga je op zoek naar 't punt waar 't mis gaat.
Of je nou debugged met een debugger en breakpoints of dat je 't nou doet door op (strategische) plaatsen een regel naar een logfile te schrijven of af te drukken op 't scherm boeit niet. Met debuggen kijk je naar de inhoud van variabelen (dus die "dump" je door ze af te drukken of in de debugger te inspecteren) en ga je na of er wel de waardes in zitten die je verwacht. Is dat niet zo dan ga je kijken hoe dat komt; en daarmee kom je uiteindelijk altijd uit op 't punt waar 't mis ging.
Als je gaat leren programmeren dan zul je eraan moeten wennen code te moeten debuggen; er is geen enkele programmeur in de wereld die foutloze code schrijft; we hebben allemaal wel eens een "oh, shit, d'uh" momentje. De één wat meer dan de ander maar we hebben 't allemaal. 't Verschil tussen een programmeur die 't redt in 't vak en de programmeur die na z'n school besluit toch maar taxichauffeur of tandarts te worden is dat de eerste zich bewust is van 't feit dat 'ie fouten maakt en ze daarna zelf leert oplossen en de tweede niet. Naar code kun je staren tot je een ons weegt; daarmee zul je vaak geholpen zijn maar als dat niet helpt dan ga je dus debuggen.

Kom je er zelfs met/na debuggen niet uit dan heb je in elk geval al 't stuk code gevonden waar 't om draait; het is dan ook zelden nodig om meer dan 10~30 regels code te plaatsen; de rest is voor je eigenlijke probleem totaal niet relevant.

egon088 schreef op zondag 20 november 2011 @ 01:06:
oeps, 0.49 dus

Nee dus. Ga nog eens terug naar de tekentafel en denk nog eens heel hard over alle operatoren die je tot je beschikking hebt en laat ons dan horen welke (combinatie van?) het geworden is. Als dat kwartje valt zul je merken dat dat veel meer voldoening geeft
Jegorex geeft 'n heel mooie hint over 0.499999.... en anders brengt dit je misschien nog op ideeën (vanaf een minuut of 6 tot een minuut of 10; of misschien moet ik schrijven >= 6min en <= 10 min ).

[ Voor 23% gewijzigd door RobIII op 20-11-2011 02:02 ]

[egonolieux]

Het is namelijk de eerste keer dat ik iets post in "programmeren", en ik ging er van uit dat hier dezelfde regels als overal in GoT gelden; "doe eerst wat moeite voor je een topic plaatst". Het is tenslotte niet zo dat ik hier code kom afschooien... Ik had tenslotte ook geen flauw idee wat er verder met debuggen bedoeld werd.

terug ontopic:

Ik weet hoe alle operatoren werken, maar ik vind het dikwijls verwarrend wiskundig gezien; 0.50 is inderdaad de helft, maar als ik zeg "kans > 0.50", dan zal hij 0.50 er niet bijtellen, dus zal het >= worden.

[bwerg]

Het random getal x is 0 <= x < 1 (volgens de documentatie die Jegorex gaf) dus als je het precies in tweeën wilt delen moet je het opdelen in 0 <= x < 0,5 en 0,5 <= y < 1, dus 0,5 >= y. Negens erachter gaan zetten werkt alleen maar verwarrend, dus doe het met inclusief en exclusief of laat het anders gewoon weg (want in dit geval maakt het waarschijnlijk niets uit welke je neemt, het verschil in kans is toch verwaarloosbaar).

[Patriot]

bwerg schreef op zondag 20 november 2011 @ 14:59:
Het random getal x is 0 <= x < 1 (volgens de documentatie die Jegorex gaf) dus als je het precies in tweeën wilt delen moet je het opdelen in 0 <= x < 0,5 en 0,5 <= y < 1, dus 0,5 >= y. Negens erachter gaan zetten werkt alleen maar verwarrend, dus doe het met inclusief en exclusief of laat het anders gewoon weg (want in dit geval maakt het waarschijnlijk niets uit welke je neemt, het verschil in kans is toch verwaarloosbaar).

Niet om 't één of 't ander, maar dat is volgens mij ook de conclusie die egon zélf trekt in de post voor je

[ Voor 0% gewijzigd door Patriot op 20-11-2011 15:17 . Reden: typo ]

[bwerg]

Ik laat alleen even zien dat het niet zo verwarrend hoeft te zijn, want als je er elke keer zo naartoe moet redeneren kan het de volgende keer weer fout gaan.

[Janoz]

Als het toch gaat om een boolean, waarom dan eerst een getal trekken? (decimaal getal op een binaire architectuur is sowieso erg lastig natuurlijk)

Je kunt natuurlijk ook gewoon de nextBoolean() van Random gebruiken.

[Hydra]

egon088 schreef op zondag 20 november 2011 @ 12:55:
Ik had tenslotte ook geen flauw idee wat er verder met debuggen bedoeld werd.

Waarom meld je dat dan niet, in plaats van te zeggen "ik heb het gelezen". Je impliceerde met je antwoord dat je al gedebugged had.

Hoe dan ook: download een IDE als eclipse; daar heb je een hele fijne debugger inzitten. Ik heb tijdens m'n studie ook aan zitten klooien met simpele texteditors en daarop terugkijkend slaat het echt nergens op dat ons geleerd werd te debuggen door zooi in de console te printen.