Programming Contest Nieuwe Stijl: Contest 4 *Score-update*

[zwippie]

Verwijderd schreef op dinsdag 13 januari 2009 @ 20:24:
...
Headers zijn imo ook nog steeds het grootste nadeel aan c++, maarja java is ook niks, daar mag je niet eens iets anders dan een class in 1 bestand zetten

Je mag wel meerdere classes in 1 bestand zetten, maar je kan inderdaad niet 1 class verspreiden over meerdere bestanden. Is dat echt zo handig dan?

[Salandur]

Verwijderd schreef op dinsdag 13 januari 2009 @ 20:24:
Ja, ik had ooit nog de code ooit nog uit de header moeten plukken, maar ooo ik ben zo lui...
Headers zijn imo ook nog steeds het grootste nadeel aan c++, maarja java is ook niks, daar mag je niet eens iets anders dan een class in 1 bestand zetten

Ja mag prima meerdere classes in 1 bestand zetten, allen het is bad practise en wordt door de meeste editors als fout aangemerkt.

offtopic:
volgende pagina niet gelezen...

[ Voor 4% gewijzigd door Salandur op 14-01-2009 10:06 ]

[Woy]

offtopic:
Ik dacht dat je in een Java bestand maar 1 public class mocht zetten. Dat was "vroeger" ieder geval zo, mischien dat dat met de tijd veranderd is.

[Creepy]

Overigens, leuk dat iedereen z'n code al online zet ( ) , maar als je geen (goede) hosting hebt wacht dan even op de uitslag want dan zetten wij ook alle entries + code online

[Megamind]

Creepy schreef op woensdag 14 januari 2009 @ 10:31:
Overigens, leuk dat iedereen z'n code al online zet ( ) , maar als je geen (goede) hosting hebt wacht dan even op de uitslag want dan zetten wij ook alle entries + code online

En de uitslag is al onderweg

[Creepy]

Geen idee, ik ben niet de lul de persoon die de entries gaat runnen

[.oisyn]

zwippie schreef op dinsdag 13 januari 2009 @ 22:05:
[...]

Je mag wel meerdere classes in 1 bestand zetten, maar je kan inderdaad niet 1 class verspreiden over meerdere bestanden. Is dat echt zo handig dan?

Blijkbaar wel, anders hadden ze die feature niet aan C# toegevoegd

Overigens vind ik het soms zelf ook wel handig, voor de wat grotere classes.

[ Voor 10% gewijzigd door .oisyn op 14-01-2009 11:23 ]

[bat266]

Is het dan alleen in de java comunity commom practice if class = big refactor to multiple classes te doen. Kan me voorstellen dat het in sommige gevallen inderdaad wel handig zou kunnen zijn. Maar is als zoiets nodig is is het meestal een teken van bad design.

[.oisyn]

Je zegt het zelf al. Meestal. Dus niet altijd. En anders moet je Sun maar mailen om te zeggen dat ze bijvoorbeeld hun java.awt.Component moeten refactoren.

[ Voor 63% gewijzigd door .oisyn op 14-01-2009 11:41 ]

[bat266]

daar heb je een punt

[bomberboy]

.oisyn schreef op woensdag 14 januari 2009 @ 11:33:
Je zegt het zelf al. Meestal. Dus niet altijd. En anders moet je Sun maar mailen om te zeggen dat ze bijvoorbeeld hun java.awt.Component moeten refactoren.

En waar zit het verschil dat ik bv. Qt of MS moet mailen als ik vind dat een of andere class te groot is of niet naar mijn persoonlijke wensen is opgebouwd?
In gelijk welke library zullen er wel stukjes zitten die niet helemaal perfect geïmplementeerd zijn.

En persoonlijk vind ik het ook niet echt duidelijker dat een mega-class in meerdere files zit of in één enkele file. Integendeel zelfs.

Maar dat is een stuk smaak en persoonlijke voorkeur natuurlijk

[Xiphalon]

Ach als de helft van de klasse gegenereerd is, is het wel makkelijk dat dat in 1 bestand gebeurd, zonder dat mijn extra's verloren gaan.

Hier wordt bijvoorbeeld een BO grotendeels gegenereerd (data access, undo, lazy linkjes naar andere BO's en vast nog veel meer) a.d.h.v. een simpel XML bestand, en kan ik me dus volledig richten op functionaliteit maken.

[.oisyn]

bomberboy schreef op woensdag 14 januari 2009 @ 12:09:
[...]


En waar zit het verschil dat ik bv. Qt of MS moet mailen als ik vind dat een of andere class te groot is of niet naar mijn persoonlijke wensen is opgebouwd?

Euh, daar zit geen verschil in, maar dat was het punt dan ook helemaal niet, dus ik snap je reactie niet helemaal. Mijn punt was dat je niet per definitie kunt zeggen dat elke grote class een product is van misdesign. Ik vind java.awt.Component daar een goed voorbeeld van, juist zo'n GUI baseclass bevat heel veel functionaliteit. En dat is ook zeer logisch. Maar als je het daar niet mee eens bent, dan zou ik graag van je horen hoe je zo'n class dan wél in elkaar zou zetten.

En persoonlijk vind ik het ook niet echt duidelijker dat een mega-class in meerdere files zit of in één enkele file. Integendeel zelfs.

Moet dat woordje "of" hier een "dan" zijn?

Maar dat is een stuk smaak en persoonlijke voorkeur natuurlijk

Klopt, en daarom is het fijn als een taal jouw daarin geen restricties gaat opleggen. Ik ben iig blij dat ik in C++ en C# de functionaliteit van classes kan categorizeren in verschillende files als dat nodig is.

[ Voor 9% gewijzigd door .oisyn op 14-01-2009 13:21 ]

[bomberboy]

O, ik had je comment verkeerd begrepen. Ik dacht dat je het als een "slecht" voorbeeld wou aanhalen. Nevermind dus.
En die "of" moet idd een dan "zijn"

[Laurens-R]

Ik vind header bestanden binnen C++ eerlijk gezegd wel een aardig concept.

Kijk het is soms even wat extra werk, maar het bied wel een mooie manier om je ontwerp (class structure) te scheiden van je implementatie code (de code van de methods zelf).

[Soultaker]

edit:
Oops, ik dacht dat we in het slechte-code-voorbeelden-topic zaten. Dit is hier wel erg off-topic, ik crosspost 'm wel even.
• Soultaker in "[alg] Slechtste programmeervoorbeelden d..."

[ Voor 96% gewijzigd door Soultaker op 14-01-2009 16:56 ]

[NMe]

Overigens kan het weer even duren voordat er nieuws is over resultaten. Ikzelf heb het druk met school, stage en de verhuizing van mijn zusje, en RobIII heeft er net een kleine bij dus die is ook redelijk afgeleid nu. Hoe het met de andere mods zit weet ik niet, maar de bezetting is dus niet optimaal, en dat met een recordaantal inzendingen.

[Soultaker]

Ik heb mijn code ook online gezet.

Uiteindelijk lijkt mijn aanpak wel veel op wat anderen deden, maar ik denk dat ik er wel op een fundamenteel andere manier toe gekomen ben. Ik ging om te beginnen uit van een soort A* achtige aanpak. Het idee hierachter is dat je het spel kunt zien als een zoekprobleem; je begint op een vaste begintoestand met een bepaalde waarde (de score) en elke keer dat je een zet doet kom je in een nieuwe toestand die een bepaalde (hogere) waarde heeft. Het doel is nu op zoek te gaan naar een pad (zeg maar, een serie zetten) die een zo hoog mogelijke eindscore oplevert.

Ik ging er vanuit dat er nauwelijks dubbele toestanden voorkomen (dat wil zeggen, ik doe geen moeite om te voorkomen dat ik meerdere keren vanuit dezelfde toestand met dezelfde score verder ga zoeken). Je kunt A* dan heel simpel implementeren, met behulp van een priority queue:

1. Gooi de begintoestand met initiële score in de priority queue.
2. Haal de toestand met de beste score uit de queue.
3. Voor elke mogelijke zet, gooi ik de nieuwe toestand met de nieuwe (hogere) score weer in de queue
4. Terug naar stap 2 (totdat de queue leeg is).

Natuurlijk is er ook een zettenlimiet van 100,000 waarna er geen zetten meer mogelijk zijn. Als je dit algoritme zo uitvoert, dan zullen toestanden waarin meer zetten gedaan zijn gemiddeld hogere scores hebben (aangezien elke geldige zet in ieder geval íets oplevert) en effectief vind je zo relatief snel een pad van de begintoestand naar de eindtoestand; backtracking is impliciet door het gebruik van de queue (als een bepaalde tak vastloopt, zitten er altijd nog oude toestanden in de queue). Helaas loopt het dan vast: het algoritme zal dan toestanden die al een hoge score hebben (dus aan het eind van het spel zitten) proberen te optimaliseren, maar daar is weinig mee te winnen. Uiteindelijk zal dit algoritme wel dé beste oplossing vinden, maar dat is alleen in theorie, want in de praktijk heb je daar geen tijd voor.

Er zijn twee dingen die ik gedaan heb om een beetje fatsoenlijke scores te halen. Het belangrijkste is dat ik de beschikbare tijd goed wilde verdelen over het spel. Daarvoor introduceer ik een tweede queue, waar toestanden tussentijds in verzameld worden. Stel dat ik maximaal 1000 zetten mag doen en ik heb 1000 seconden om te rekenen, dan gaan op tijdstip T alle stellingen die ik vind waarin exact T zetten gedaan zijn, niet terug in de eerste queue, maar in de tweede queue, waar ze moeten wachten. Ik ga er dus nog niet mee verder rekenen. Pas op tijdstip T+1 gooi ik de inhoud van de tweede queue bij de eerste (en maak de tweede daarna leeg). Zo forceer ik dat mijn algoritme (bijvoorbeeld) halverwege de tijd ook halverwege het spel aan het rekenen is.

Het effect daarvan is dat het hele spel door gezocht wordt, zonder dat ik me tussentijds vastleg op één stelling (zoals bijvoorbeeld .oisyn in een van zijn eerste versies deed, als ik het goed begrijp) of op één generatie (beste X takken van diepte T) zoals anderen doen. Tenminste, dat is de theorie; ik heb het idee dat in de praktijk toch alleen stellingen van diepte T bekeken worden, vandaar waarschijnlijk dat ik niet veel hogere scores haal dan andere mensen die gewoon per zet de top-X beste toestanden bijhouden.

Ten slotte kan de queue snel heel erg groot worden, en het invoegen en verwijderen van elementen wordt dan heel erg traag. Om dat te voorkomen, stel ik een maximumgrootte voor de queue in, en als die bereikt is, gooi ik de laagst scorende elementen er weer uit om ruimte te maken voor nieuwe elementen.

[DaCoTa]

Soultaker schreef op woensdag 14 januari 2009 @ 17:19:
Ik heb mijn code ook online gezet.
<knip>

Dit lijkt toch ook wel heel erg op mijn oplossing. Met als verschil dat ik geen grote gezamelijke queue heb, alleen de losse queue's voor iedere stap waar dus op een bepaalde tijdstip alleen maar aan gerekend mag worden.

Het duurste stuk van mijn algoritme is nu het toevoegen aan die queue's. Daarom heb ik een vrij strakke threshold om iets toe te laten. Gevaar daarin zit hem dat het algoritme kan verhongeren.

Ik wil mijn algoritme wel eens aanpassen aan jouw systeem, klinkt nog wel als een leuk experiment. Wat ik wel interessant vind, is dat je het sorteren kan beperken tot de momenten dat je van stap gaat wisselen. Dus daar is theoretisch veel tijd mee te besparen. Mss vanavond wat testresultaten

[ Voor 11% gewijzigd door DaCoTa op 14-01-2009 17:51 ]

[.oisyn]

Soultaker schreef op woensdag 14 januari 2009 @ 17:19:
Het effect daarvan is dat het hele spel door gezocht wordt, zonder dat ik me tussentijds vastleg op één stelling (zoals bijvoorbeeld .oisyn in een van zijn eerste versies deed, als ik het goed begrijp) of op één generatie (beste X takken van diepte T) zoals anderen doen.

Klopt, in eerste instantie gebruikte ik de eerste methode. Daarmee kwam ik tot een score van pakweg 46M op de standaard testset door een stuk of 2 zetten vooruit te denken en een hogere score toe te kennen aan zetten die lager in het veld zaten en blokjes die meer voorkomen.

[Soultaker]

DaCoTa schreef op woensdag 14 januari 2009 @ 17:49:
Ik wil mijn algoritme wel eens aanpassen aan jouw systeem, klinkt nog wel als een leuk experiment.

Ik dacht dat jij hogere scores haalde momenteel, dus ik betwijfel of daar winst mee te behalen is; of je moest überhaupt sneller zetten kunnen genereren enzo. (Dat is ook wel aardig om te vergelijken; mijn verifier was b.v. significant sneller dan die van .oisyn, als ik die met Wine draaide, maar dat op zich zegt niet zoveel.)

Wat ik wel interessant vind, is dat je het sorteren kan beperken tot de momenten dat je van stap gaat wisselen. Dus daar is theoretisch veel tijd mee te besparen.

Dat is wel een leuk idee; bij mij was trouwens het queuen niet echt een grote bottleneck, dus ik weet niet of er echt veel mee te winnen is. (Overigens moet ik wel twee echte queues bijhouden omdat ik ze op grootte limiteer, en ik dus efficient de slechtste state wil kunnen weggooien als ik ruimte nodig heb.)

[KoW]

Soultaker schreef op woensdag 14 januari 2009 @ 17:19:
Uiteindelijk lijkt mijn aanpak wel veel op wat anderen deden, maar ik denk dat ik er wel op een fundamenteel andere manier toe gekomen ben. Ik ging om te beginnen uit van een soort A* achtige aanpak. Het idee hierachter is dat je het spel kunt zien als een zoekprobleem; je begint op een vaste begintoestand met een bepaalde waarde (de score) en elke keer dat je een zet doet kom je in een nieuwe toestand die een bepaalde (hogere) waarde heeft. Het doel is nu op zoek te gaan naar een pad (zeg maar, een serie zetten) die een zo hoog mogelijke eindscore oplevert.

erm, volgens mij schiet mijn kennis hier te kort.

Maar een serie van zetten met als einddoel een zo hoog mogelijke score, waarbij steeds de toestand met de hoogst mogelijke score wordt genomen, dat is toch precies hetzelfde als:

• Kijk naar de beste zet
• Neem die en kijk weer naar de beste zet

Hoe zit dat, het best mogelijke pad vinden er dan uit?

[Verwijderd]

Ik denk het niet, want als je als einddoel de hoogste score hebt, kan het best zijn dat je in tussentijd een minder goede zet hebt gedaan om op dit pad uit te komen. Wat dus uiteindelijk een betere score oplevert.
Zo werkt A* star toch ook? Het goedkoopste pad vinden naar een einddoel.

[ Voor 14% gewijzigd door Verwijderd op 14-01-2009 20:09 ]

[KoW]

Ja, maar hoe definieer je je einddoel dan?

Komt dit algoritme er dan op neer dat je alle mogelijke paden doorrekend?

En, het sample op wikipedia heeft het over knooppunten, wat zijn dan je knooppunten.
Wanneer een score je knooppunt is, komt er toch altijd per stap de zet met de dan hoogste score uit. Of zet je dan knooppunten uit b.v. elke 10.000 punten en bereken je daarbinnen alle paden om het beste pad tot aan de 10.000 te vinden?

[Verwijderd]

Je hoeft geen einddoel je definieren, je zorgt dat je algoritme paden doorloopt en vergelijkt de score van die paden met elkaar tot je de hoogste overhoudt. Je knooppunt zou een geldige zet kunnen zijn, daar ken je immers een waarde aan toe.
Misschien dat de auteur van de code wat meer verheldering kan bieden

[Janoz]

KoW schreef op donderdag 15 januari 2009 @ 13:36:
Ja, maar hoe definieer je je einddoel dan?

Komt dit algoritme er dan op neer dat je alle mogelijke paden doorrekend?

Ja, in principe zul je op een gegeven moment alle mogelijke situaties in je queue hebben staan 'gesorteerd'* op hoogste score. In de praktijk is dat niet haalbaar natuurlijk aangezien er daarvoor niet genoeg geheugen is. Vandaar dat op een gegeven moment de meest ongezonde weggegooid worden.


* voor zover je kunt spreken van gesorteerd in een priority queue

En, het sample op wikipedia heeft het over knooppunten, wat zijn dan je knooppunten.
Wanneer een score je knooppunt is, komt er toch altijd per stap de zet met de dan hoogste score uit. Of zet je dan knooppunten uit b.v. elke 10.000 punten en bereken je daarbinnen alle paden om het beste pad tot aan de 10.000 te vinden?

Een move is een knooppunt. Je neemt echter niet alleen de beste, maar allemaal. Je stopt de resultaten van alle zetten weer in je queue.

Soultaker schreef op woensdag 14 januari 2009 @ 17:19:
Ik heb mijn code ook online gezet.
Natuurlijk is er ook een zettenlimiet van 100,000 waarna er geen zetten meer mogelijk zijn. Als je dit algoritme zo uitvoert, dan zullen toestanden waarin meer zetten gedaan zijn gemiddeld hogere scores hebben (aangezien elke geldige zet in ieder geval íets oplevert) en effectief vind je zo relatief snel een pad van de begintoestand naar de eindtoestand; backtracking is impliciet door het gebruik van de queue (als een bepaalde tak vastloopt, zitten er altijd nog oude toestanden in de queue). Helaas loopt het dan vast: het algoritme zal dan toestanden die al een hoge score hebben (dus aan het eind van het spel zitten) proberen te optimaliseren, maar daar is weinig mee te winnen. Uiteindelijk zal dit algoritme wel dé beste oplossing vinden, maar dat is alleen in theorie, want in de praktijk heb je daar geen tijd voor.

Wat nu wanneer je als sorteringscriteria niet de score, maar de score per move zou nemen?

[ Voor 34% gewijzigd door Janoz op 15-01-2009 14:44 ]

[KoW]

Dan is dat algoritme niet veel anders dan het mijne.

Ik probeer ook steeds de zetten door te rekenen die de hoogste gemiddelde score per move hebben. Om te voorkomen dat alleen de volgende zet steeds bekeken wordt mag een pad alleen gekozen als het minimaal zoveel zetten diep is. (Daardoor kan het voorkomen dat de code een aantal rekencycli staat te wachten totdat er weer een pad is met een hoge gemiddelde score )

Bij deze ook de beloofde laatste update 11-01-2009
Deze versie haalt vooral op de grotere sets 30 tot 40% meer score.

[BalusC]

De T.net file storage is afaik niet public. In ieder geval meldt dat linkje "unknown file".

[Janoz]

KoW schreef op vrijdag 16 januari 2009 @ 12:14:
Dan is dat algoritme niet veel anders dan het mijne.

Eerder gaf je aan dat jouw algorithme bestaat uit:

* Kijk naar de beste zet
* Neem die en kijk weer naar de beste zet

Daaruit maak ik op dat je op een veld maar 1 zet doet, namelijk de beste. Soultakers algorithme doet alle mogelijke zetten.

[KoW]

Janoz,

Dat was een reactie op iemand anders.
De uiteindelijke bepaling welke zet berekend wordt gebeurd op:
paddiepte = zetdiepte - laatst gekozen zet diepte
paddiepte * 20 + (zetscore - laatste gekozen zet score) / paddiepte

Welke zet gekozen word als volgende zet is alleen bepaald op de gemiddelde score waarbij wel een minimale paddiepte is vereist.

Hierbij een nieuwe poging dan:
http://people.zeelandnet.nl/kwisse/GoT4a.zip

[Soultaker]

Janoz schreef op donderdag 15 januari 2009 @ 14:24:
Wat nu wanneer je als sorteringscriteria niet de score, maar de score per move zou nemen?

Dat is een goede suggestie, en ik heb dit ook bedacht en geprobeerd ergens in het begin; ik geloof dat dit er juist weer toe leidde dat er helemaal aan het begin van het spel geoptimaliseerd wordt en dat is ook weer niet de bedoeling, want uiteindelijk telt alleen de eindscore (honderd zetten van 1000 punten zijn nog altijd slechter dan honderd duizend zetten van 10 punten gemiddeld).

Wellicht dat een combinatie van de twee criteria of een andere koppeling aan de tijd (na verloop van tijd de stellingen vroeg in het spel uit de queue gooien b.v.) wel goed zou werken. Ik moet bekennen dat ik er vanwege tijdgebrek veel te weinig mee geëxperimenteerd heb.

[compufreak88]

Aardig stil hier. Al enig idee wanneer er resultaten komen?

[KoW]

daar zou ik niet te ongeduldig mee zijn.
Het runnen van de code alleen al duurt al 2 dagen minimaal (nog zonder de extra tests op robuustheid), en het doornemen van de code op een zinvolle manier kost ook wel een dag per inzending.
Kortom, als je ergens begin/halverwege februari een uitslag hebt is dat al vrij snel.

(Er van uit gaande dat de mods wel een prive leven hebben )

[Janoz]

Bedenk daarnaast dat een groot gedeelte van de devschuur crew ook een baan, vrouw en kinderen heeft waardoor de doorlooptijd best op kan lopen.

[NMe]

Bovendien heb ik dit vorige week gepost:

NMe schreef op woensdag 14 januari 2009 @ 17:03:
Overigens kan het weer even duren voordat er nieuws is over resultaten. Ikzelf heb het druk met school, stage en de verhuizing van mijn zusje, en RobIII heeft er net een kleine bij dus die is ook redelijk afgeleid nu. Hoe het met de andere mods zit weet ik niet, maar de bezetting is dus niet optimaal, en dat met een recordaantal inzendingen.

[king_charles]

Better late than never: Hier is mijn source

[mocean]

Megamind schreef op maandag 12 januari 2009 @ 13:31:
[...]

Opzich zou het leuk zijn deze weer door te starten, weer eens iets anders.

Misschien een 4 maanden deadline over een maandje of 2-3.

Dat was ook een leuke, heb nog wat botjes. Wat er misging imho is dat de server-implementatie(s) ook steeds werden geupdate. Beter zou zijn 1 server af te hebben met de gestelde regels volledig geimplementeerd, en dan de contest starten. Was laatst nog ergens een topic over, of er nog servers waren.

Vond het vooral een mooie contest omdat iedereen kan werken vanuit zn eigen pc, processor snelheid speelde niet echt een rol, en je kan battles organiseren.

[Verwijderd]

Verwijderd schreef op dinsdag 13 januari 2009 @ 20:24:
...
Headers zijn imo ook nog steeds het grootste nadeel aan c++, maarja java is ook niks, daar mag je niet eens iets anders dan een class in 1 bestand zetten

Interfaces
Enumerations

[Verwijderd]

mocean schreef op donderdag 22 januari 2009 @ 18:53:
[...]

Dat was ook een leuke, heb nog wat botjes. Wat er misging imho is dat de server-implementatie(s) ook steeds werden geupdate. Beter zou zijn 1 server af te hebben met de gestelde regels volledig geimplementeerd, en dan de contest starten. Was laatst nog ergens een topic over, of er nog servers waren.

Vond het vooral een mooie contest omdat iedereen kan werken vanuit zn eigen pc, processor snelheid speelde niet echt een rol, en je kan battles organiseren.

offtopic:
Daar ben ik het helemaal mee eens. Dat is sowieso ook leuk voor programmeurs die qua algoritme niet zo goed zijn, maar het werken met sockets heel leuk vinden etc.

[NMe]

Betekent meteen dat je veel tijd kwijt bent aan triviale zaken als het opzetten van de connectie en het implementeren van het juiste protocol, terwijl de focus bij een contest juist op de niet-triviale zaken zou moeten liggen.

Overigens zijn we er nog, het beoordelen van deze contest is nogal op een laag pitje komen te staan. Gaat allemaal goedkomen.

[Dirk]

Jullie hebben dus écht nog een leven náást GoT?

[Alain]

NMe schreef op dinsdag 03 maart 2009 @ 10:38:
Overigens zijn we er nog, het beoordelen van deze contest is nogal op een laag pitje komen te staan. Gaat allemaal goedkomen.

Ik vind het erg slecht dat dit op een laag pitje staat. Ik snap dat jullie sociale verplichtingen hebben, maar het is niet alsof het uit de lucht komt vallen. Ik zag de contest te laat en kon niet meer meedoen, maar in 2 maanden kan ik wel iets in elkaar sleutelen, waardoor ik toch mee had kunnen doen.

[NMe]

En tóch gaat ons sociale leven voor. Die deadline was er ook meer voor jullie om te zorgen dat er toch écht een grens is, niet zozeer voor ons omdat het ons wat tijd betreft lekker uit kwam. Want dat kwam het dus niet.

[Alain]

NMe schreef op dinsdag 03 maart 2009 @ 22:53:
Die deadline was er ook meer voor jullie om te zorgen dat er toch écht een grens is

Om het vervolgens links te laten liggen?

Als je er de komende maanden toch niks mee doet, laat het dan open voor iedereen.

[NMe]

Waardoor vervolgens iedereen denkt "ach, tijd zat, komt nog wel" waardoor het blijft liggen en nooit afgemaakt wordt? Er moet gewoon een deadline zijn die redelijk dichtbij (maar niet té dichtbij) in de toekomst ligt. Zonder goed afgebakende set regels eindigt het vanzelf in een sisser, net zoals de BotWars-contest.

En verder kan ik er ook niet veel meer van zeggen. We hebben het allemaal druk gehad, gaat in de komende tijd niet veel beter worden maar ik ga proberen een en andere in het weekend ertussen te frotten.

[Alain]

NMe schreef op dinsdag 03 maart 2009 @ 23:39:
Waardoor vervolgens iedereen denkt "ach, tijd zat, komt nog wel" waardoor het blijft liggen en nooit afgemaakt wordt? Er moet gewoon een deadline zijn die redelijk dichtbij (maar niet té dichtbij) in de toekomst ligt.

Je hebt zonder meer gelijk. Ik zou dit juist door willen trekken naar de organisator(en). De beoordeling heeft geen deadline. Begrijp me niet verkeerd, het is jullie goed recht om van je sociale (en misschien wel asociale) leven te genieten. Ik vind het alleen niet eerlijk om een deadline te stellen tegenover anderen en deze voor jezelf niet te stellen. Het is alsof iemand je leert plannen, maar zelf absoluut niet kan plannen.

[NMe]

Je hebt ook wel gelijk hoor, maar 't is gewoon niet zo uit gekomen. Los daarvan is de contest zelf wel geslaagd en het meedoen is (IMO) leuker dan de uiteindelijke score. Die score komt uiteraard ook wel, maar laat nog even op zich wachten.

[RobIII]

NMe schreef op dinsdag 03 maart 2009 @ 23:57:
Je hebt ook wel gelijk hoor, maar 't is gewoon niet zo uit gekomen. Los daarvan is de contest zelf wel geslaagd en het meedoen is (IMO) leuker dan de uiteindelijke score. Die score komt uiteraard ook wel, maar laat nog even op zich wachten.

Ook ik vind dat AlainS een punt heeft en, op persoonlijke noot, ik zou er graag wat harder aan trekken. Helaas ben ik (niet om mezelf in te dekken, ik geef gewoon even een beeld van hoe het er voor staat) wat overdonderd door de vroegtijdige geboorte van onze Danu en heb ik naast het modereren en een drukke baan ook nog een flink project voor de avonduren op mijn hooivork welke wat ruimer was geplanned maar helaas door Danu overhoop gegooid is . Als ik al tijd zou hebben voor een sociaal leven (op dit moment is het écht 0 namelijk; slapen, werken, eten en een paar minuten in de avond voor de kids) dan nam ik graag wat van die werklast op me, maar dat zit er nu even écht niet in. En nu je mijn redenen kent kan ik je verklappen dan je van de anderen hier niet veel anders horen; ze hebben dan wellicht geen nieuw leven op de aarde gezet afgelopen 2 maanden maar zijn nét zo druk als ik.
Het heeft echter wel onze aandacht en prioriteit en NMe, de rest en ik doen ons best het zo spoedig mogelijk af te ronden; we beseffen terdege dat het ook voor jullie leuker zijn om 2 dagen na deadline de uitslag te krijgen.

[bomberboy]

Ik sluit me ook aan bij AlainS. Ik vrees ook dat dit de populariteit van de contest niet ten goede komt. Bij de vorige contest was het eigenlijk al hetzelfde verhaal. Maar ik wou toch nog eens opnieuw meedoen, ook omdat de opgave me nu iets meer aansprak. Maar de motivatie om in de toekomst nog eens deel te nemen is nu wel heel klein geworden.

Ik begrijp ook wel dat het hoofddoel van de contest is om mensen aan te trekken op het forum en ze hier ook te houden. Maar indien het zo lang onduidelijk blijft kan dit even goed een averechts effect krijgen.
Zeker omdat er eigenlijk geen informatie of deadline is. Persoonlijk vind ik een vooropgestelde datum 3 maand in de toekomst minder vervelend dan gewoon de melding "we zien wel wanneer we eens tijd en/of zin hebben".

[Soultaker]

Hier ben ik het in ieder geval wel mee eens:

NMe schreef op dinsdag 03 maart 2009 @ 23:39:
Er moet gewoon een deadline zijn die redelijk dichtbij (maar niet té dichtbij) in de toekomst ligt. Zonder goed afgebakende set regels eindigt het vanzelf in een sisser, net zoals de BotWars-contest.
[..] Los daarvan is de contest zelf wel geslaagd en het meedoen is (IMO) leuker dan de uiteindelijke score.

Ik ga ook verder niet klagen over de gang van zaken want de moderators zijn i.m.o. al ver aan hun plicht voorbij gegaan door überhaupt zo'n contest te organiseren, dus eisen stellen aan de kwaliteit van de afwikkeling ervan lijkt me niet terecht.

Aan de andere kant heb ik wel wat suggesties voor jullie om het pragmatisch aan te pakken. Ik zou er sowieso voor gekozen hebben om een aantal zaken al van te voren voor te bereiden, zoals het maken van de testopgave en bepalen hoe tests uitgevoerd worden (welke PC, welk OS, wrapper scriptje, et cetera) zodat je dat alvast gehad hebt. Je kunt dit prima tijdens de looptijd van de contest voorbereiden, en het scheelt op het eind toch wel een heleboel werk. Maar goed, daar valt nu natuurlijk niet meer zoveel aan te doen.

Uit de topic start wordt trouwens niet helemaal duidelijk welke categoriën jullie willen beoordelen en hoe dat precies moet gebeuren; dat moet sowieso bepaald worden. Los daarvan is het misschien aardig om een lijstje van deelnemers te posten. Die twee dingen samen bepalen wat je nog moet doen, lijkt me.

Hoogste score

• Iemand moet een test set maken, waarschijnlijk kun je die gewoon random genereren aan de hand van zelfgekozen parameters. Ik heb overigens ook wel een Python script om random cases te genereren als je tijd wil besparen, dan genereer je gewoon een paar dozijn en kies je, zeg, 10 verschillende cases die je er leuk uit vind zien.
  edit: Ik bedenk nu dat jullie gezien de tijdlimiet waarschijnlijk maar met één case willen testen. Die kun je nog wel met de hand construeren, hoewel je dan ook wel een leuke random case kunt nemen.
• Daarna moet iemand alle inzendingen runnen op eenzelfde systeem. Daarvoor zou ik eerst een scriptje/programma schrijven dat makkelijk een willekeurige inzending kan runnen op een willekeurige test set, automatisch afbreekt als de tijd verstreken is, en de score berekent. Dit kost een hoop executietijd, maar als je het een beetje handig automatiseert hoef je er niet de hele tijd bij te zitten.

Robuustheid code

• Ook hier moet weer een test set gemaakt worden met rare randgevallen en andere troep erin.
• Verder moet duidelijker gedefinieerd worden hoe je programma's beoordeelt; wat moet er precies gebeuren als een bestand niet aan de invoer voldoet? Moet het programma toch proberen de case uit te voeren, of is het voldoende om een fout in de invoer te signaleren?
• Tenslotte moeten ook weer alle programma's op de test set gerund worden.

Kwaliteit code

• Altijd subjectief natuurlijk, maar wederom niet duidelijk gedefinieerd.
• Mischien is het mogelijk om dit d.m.v. peer reviews te doen, waarbij deelnemers inzendingen van anderen maar in dezelfde programmeertaal beoordelen? Vereist misschien wat puzzelen om reviewgroepjes te maken die zinnig zijn, en je krijgt er geen globale winnaar mee, maar ik denk dat het sowieso lastig is verschillende talen/platforms direct met elkaar te vergelijken. (Eventueel zou je als organisatie nog uit de winnaars van alle groepjes een overall winnaar kunnen kiezen.) Het voordeel van zo'n opzet zou zijn dat je het beoordelen van code (wat veel werk is) kunt offloaden op de deelnemers, wat veel werk bespaart. Je zou ook het testen van randgevallen (zie vorige categorie) uitbesteden omdat het niet echt systeemafhankelijk is.

Geen idee in hoeverre jullie al over dit soort dingen nagedacht hebben (dat wordt namelijk niet echt naar buiten gecommuniceerd ) maar dit is ongeveer hoe ik het aan zou pakken. Ik zou er in dit stadium (en gezien het feit dat tijd schaars is) in ieder geval voor kiezen om de boel zo te organiseren dat het werk dat jullie er als organisatie nog in moeten steken beperkt is.

bomberboy schreef op woensdag 04 maart 2009 @ 10:29:
Persoonlijk vind ik een vooropgestelde datum 3 maand in de toekomst minder vervelend dan gewoon de melding "we zien wel wanneer we eens tijd en/of zin hebben".

Aan een vaste datum heb je ook niets als er geen plan van aanpak is, en als die er wel is, dan hoeft het niet zo lang te duren.

[ Voor 6% gewijzigd door Soultaker op 04-03-2009 11:38 ]

[Creepy]

Soultaker: de vorige contest hebben we ook op alle drie de zaken beoordeeld dus dat zal niet anders gaan dan de vorige keren. 1 persoon zal alle entries op hetzelfde systeem draaien voor de hoogste score. De robuustheid test kan inderdaad door meerdere personen worden gedraaid. Vervolgens zullen er meerdere mods van alle entries de code bekijken en beoordelen op kwaliteit.

Op het moment dat de uitslag bekend is worden de gegevens gepost (deelnemers de scores etc) inclusief alle test sets.

[Soultaker]

Ok, dus er is wel over nagedacht.
Dan wacht ik nog rustig af.

[NMe]

Soultaker schreef op woensdag 04 maart 2009 @ 11:39:
Ok, dus er is wel over nagedacht.

Niet in zoveel detail als je het nu uitschrijft, maar er is een dergelijke routine, zeg maar.

[Pete]

Sorry dat ik de waarschuwing negeer, maar het is alweer een maand verder. Kan de crew al enige indicatie geven wanneer de resultaten er komen?

Voor de volgende keer, kunnen jullie meer mensen betrekken bij de organisatie van de contest? Ik denk dat er devschuur bezoekers genoeg zijn die hier bij willen helpen.

[Woy]

Er word druk aan gewerkt. NMe was er mee bezig, maar door een crash van zijn video kaart, moeten de metingen opnieuw gedaan worden. Helaas dus nog even geduld, maar ik denk dat het niet lang meer op zich laat wachten. ( Maar voor mij is dat makkelijk praten, aangezien ik er niet mee bezig ben )

[NMe]

Inderdaad, ik had eindelijk een gaatje gevonden om de meeste dingen te checken, maar tussen twee tests door aan het einde van mijn lijst begaf mijn graka het. Ik ben daarna doorgegaan met alles opnieuw te laten lopen op mijn laptop (die redelijk vergelijkbaar is kwa specs) maar heb de tijd niet kunnen vinden om dat af te ronden. Ik hoop/denk tegen het eind van de week weer wat tijd te hebben.

Het spijt me dat dit zo lang duurt, zeker omdat het alweer de tweede keer is. We hebben het ineens allemaal collectief druk, wat net samenviel met het inleveren van de contest. De volgende keer zullen we daar wat meer op letten en als het fout dreigt te lopen roepen we wel hulp in.

[KoW]

Wellicht is het ook een idee om de deadline voor het inleveren van je resultaat ook wat ruimer te zetten.
Net als de mod's hebben ook gewone gotters soms te weinig tijd.

[Dirk]

Er was zat tijd voor de contest, daar hoefde echt niets bij. Dat de modjes vervolgens problemen kregen met de verwerking van de input door wat slecht planbare zaken kunnen ze ook weinig aan doen.

[bomberboy]

Zag ik plots ongelezen berichten in deze thread en dacht ik toch wel dat de uitslag bekend was zeker...

Mss een ideetje voor de volgende contest om de resultaten te laten evalueren door de deelnemers zelf?

[NMe]

Dirk schreef op woensdag 22 april 2009 @ 23:24:
Er was zat tijd voor de contest, daar hoefde echt niets bij. Dat de modjes vervolgens problemen kregen met de verwerking van de input door wat slecht planbare zaken kunnen ze ook weinig aan doen.

Nou, dit was iets dat ik van tevoren deels had kunnen weten. Ik ben bezig met mijn afstuderen (stage), tegelijkertijd nog wat vakken af aan het ronden, bijbaantje erbij, veel reistijd dagelijks. Er is echter ook niet echt iemand die het zo snel even van me over kan nemen dus ik moet er zelf een gaatje voor vinden.

[KoW]

Dirk schreef op woensdag 22 april 2009 @ 23:24:
Er was zat tijd voor de contest, daar hoefde echt niets bij. Dat de modjes vervolgens problemen kregen met de verwerking van de input door wat slecht planbare zaken kunnen ze ook weinig aan doen.

Dat klinkt erg logisch

De users weten niet van te voren dat er een contest aan komt en die hebben hun zaken zo geplanned dat er altijd tijd is voor een contest tussendoor.
De mod's daarentegen hebben zelf de contest geplanned en hebben vanwege hun planning de 4 maanden na de contest geen tijd.

Even afgezien van de situatie vind ik je redenatie niet erg sterk.

[Snake_Y_]

Zou het niet beter zijn al een andere contest te starten terwijl er gewacht wordt op de uitslag?

Ik dacht hier ergens gelezen te hebben dat de volgende contest al in de steigers stond...

[NMe]

Ik rond liever eerst deze contest af. Dit weekend moet het er maar van gaan komen.

[Snake_Y_]

Ok, Good luck

[Matis]

NMe schreef op dinsdag 05 mei 2009 @ 21:56:
Ik rond liever eerst deze contest af. Dit weekend moet het er maar van gaan komen.

Ik weet dat het weekend nog 3 uur duurt en voor een echte tweaker nog minimaal 6, maar hoe staat het met het benchmarken?

Zit al vol smart te wachten op een nieuwe contest!

[roy-t]

toaomatis schreef op zondag 10 mei 2009 @ 20:50:
[...]


Ik weet dat het weekend nog 3 uur duurt en voor een echte tweaker nog minimaal 6, maar hoe staat het met het benchmarken?

Zit al vol smart te wachten op een nieuwe contest!

Klopt ik ben er helemaal klaar voor . Deze komende maanden eindelijk tijd om mee te doen.

[NMe]

Dat ik er wat werk aan verzet wil nog niet zeggen dat het direct af is natuurlijk. Ik ben op weg in elk geval.

[roy-t]

NMe schreef op dinsdag 12 mei 2009 @ 02:05:
Dat ik er wat werk aan verzet wil nog niet zeggen dat het direct af is natuurlijk. Ik ben op weg in elk geval.

Oh nee joh, maar we wachten kwijlbekkend gewoon af

[Matis]

roy-t schreef op dinsdag 12 mei 2009 @ 12:55:
Oh nee joh, maar we wachten kwijlbekkend gewoon af

Haha, ik ook. Heb deze weken mooi de tijd (stage ). Ik heb nog wel een aantal leuken ideeen, maar weet niet of dit de goede plek is om te posten.

[boe2]

Is het nog ver?

Kijk er echt naar uit om mee te kunnen doen met de volgende contest

[- peter -]

Jep, ik ga dit keer ook meedoen, lijkt me leuk!

[Verwijderd]

Ik ook. Goede oefening op mijn zelfstandige programmerstudies!

[roy-t]

Noes, nog steeds geen nieuws? Enige datum dat men denkt dat de uitslag klaar is? Tis immers al goed 5 maanden sinds de doodlijn.

[mocean]

roy-t schreef op zondag 24 mei 2009 @ 13:49:
Noes, nog steeds geen nieuws? Enige datum dat men denkt dat de uitslag klaar is? Tis immers al goed 5 maanden sinds de doodlijn.

Ik heb niet eens meegedaan maar het wordt wel een beetje genant als je na 5 maanden nog geen uitslag kan produceren. Heb veel meegelezen, ook gedacht over oplossingen en ik ben wel benieuwd naar de uitslag.

[ Voor 11% gewijzigd door mocean op 25-05-2009 00:48 ]

[Twazerty]

Hoogst waarschijnlijk ga ik de volgende contest wel meedoen tenzij het onderwerp mij totaal niet aanstaat. Ben er nu klaar voor iig. Dus kom maar op met de uitslag en de nieuwe contest.

[Verwijderd]

Vind dit wel absurd lang

[ Voor 17% gewijzigd door Verwijderd op 29-05-2009 00:12 ]

[NMe]

Niet om het een of ander maar dit is je eerste post in dit topic en ik kan me zo ook geen inzending van je herinneren?

Ja het duurt lang, ja dat is stom, ja dat is onze fout. En ja, daar gaan we wat aan doen; ik heb zelf dit weekend volledig uitgetrokken voor de contest en ik geloof dat Rob ook wat eraan gaat knutselen, dus het licht aan het eind van de tunnel is bijna in zicht.

[Verwijderd]

Dat klopt. Maar ik was al een tijd aan het wachten op de resultaten.

[Megamind]

Verwijderd schreef op zaterdag 30 mei 2009 @ 07:58:
Dat klopt. Maar ik was al een tijd aan het wachten op de resultaten.

Dat doen we allemaal Maar wat maakt het nou uit, het kost toch geen geld Het is allemaal voor de lol, en als het niet uitkomt, ok dan wachten we gewoon.

[KoW]

Zoveel verwacht ik niet van mijn eigen brouwsel, maar het zou wel leuk zijn wanneer de uitslag nog net binnen het half jaar bekend is

Misschien nog eens kijken naar de oplossingsmethoden die anderen hebben toegepast.
Worden dit soort problemen eigenlijk standaard op school "geleerd"?

[ Voor 50% gewijzigd door KoW op 01-06-2009 19:47 . Reden: dubbel ]

[dcm360]

KoW schreef op maandag 01 juni 2009 @ 19:41:
Zoveel verwacht ik niet van mijn eigen brouwsel, maar het zou wel leuk zijn wanneer de uitslag nog net binnen het half jaar bekend is

Dat is nog t/m 12 juli (12 juni is 5 maanden)

Misschien nog eens kijken naar de oplossingsmethoden die anderen hebben toegepast.
Worden dit soort problemen eigenlijk standaard op school "geleerd"?

Ben ik ook wel benieuwd naar eigenlijk. Er zijn vast wel methodes om dit soort problemen gestructureerd op te lossen, maar ik denk niet dat die de hoogste efficientie zullen halen. Iedereen denkt op zijn of haar eigen manier na en vindt dus ook op zijn of haar eigen manier een oplossing. Als je al bekijkt hoe verschillend mannen en vrouwen problemen oplossen, lijkt het mij dat de methode per geslacht flink kan verschillen.
Mijn methode is trouwens het volgende: Veel A4tjes, memoblaadjes, pennen, stiften, potloden en gummen en daarmee aan de slag gaan. Voor dit betrekkelijk simpel probleem heb ik iets van 10 A4tjes volgekladderd En helaas, structuur daarin ontbreekt bij mij nogal... Als ik nu mn aantekeningen zou terugvinden zou ik niet meer weten waarom ik alles zo neergezet heb. Als ik echter mn code bekijk kan ik wel weer beargumenteren waarom ik bepaalde keuzes gemaakt heb. (en ook waarom ik dingen heb weggelaten: tijdgebrek).

[NMe]

Daar zijn ze dan!

#	Naam	Score	Run tijd (minuten)	Ongeldige zet na	Totaal aantal zetten	Commentaar
1	DaCoTa	36.321.800	15		100.000
2	.oisyn	35.616.000	15		100.000
3	Bomberboy/neonlamp	35.321.100	15		100.000
4	Pete	34.562.850	15		100.000	Niet met "java -Xms128m -Xmx2500m -server -jar jewelsmit.jar" gerund maar met "java -Xms128m -Xmx1024m -jar jewelsmit.jar"
5	Soultaker	33.124.300	15		99.998	Uit zichzelf gestopt, maar mist toch twee moves?
6	dotcode	27.542.500	14		100.000
7	TweakPino	27.284.500	15		92.900
8	.knop	23.849.900	11		100.000
9	TheFoxNL	20.879.000	15		100.000
10	zwippie	20.403.300	9		100.000	Invalide uitvoer.txt, per move stond de score erachter vermeld. Genoemde score is na het repareren van die uitvoer.
11	king_charles	19.491.000	15		100.000
12	KoW	11.519.100	15		100.000
13	DCM360	1.191.600	1		7.878
14	Megamind	34.450	15	393	100.000	Melding "Er zit een rare gem in kolommen.txt, ik zal deze gewoon overslaan." een aantal keer voor programma start
15	BalusC	23.900	6	303	100.000
16	vistu	2.850	5	13	100.000
17	compufreak88	2.150	15		100.000
18	PinQ	0	0		0	Foutmelding in Windows, geen logging
18	veldsla	0	0		0	Error: illegal instruction
18	DirkW	0	0		0	Lijkt helemaal niets te doen

Een mooier opgemaakte lijst, linkjes naar inzendingen, resultaten en de validator en de resultaten van de code review komen nog, maar nu kunnen jullie in elk geval vooruit.

[ Voor 4% gewijzigd door NMe op 02-06-2009 03:22 ]

[Soultaker]

WTF, scores!!

Maar dit is toch niet alles? Waar zijn .oisyn, Eskimootje en ik?

[NMe]

.oisyn heeft niks ingestuurd voor zover ik weet, en van jou en Eskimootje heb ik ook niks? Als jullie het nu nog even doorsturen wil ik die scores ook nog wel even uitstampen voordat we de definitieve scores in de tweede post van het topic zetten.

[Soultaker]

Had .oisyn zichzelf dan als ex-crew uitgesloten van deelname ofzo? Want hij had zeker wel een solver gebouwd.

Ikzelf heb op 7 januari mijn inzending gemaild naar [e-mail], maar die is blijkbaar niet aangekomen?! (Volgende keer misschien iets doen met confirmatie in het topic o.i.d. van ontvangen inzendingen?) Ik kan 'm nog wel een keer opsturen, maar waar moet 'ie heen dan (als [e-mail] blijkbaar niet doorkomt?)

edit:
Ik zie zo het topic scannende nog wel meer mensen die claimen iets werkends te hebben en/of in te willen zenden, hoewel ik natuurlijk niet weet of die ook daadwerkelijk iets gestuurd hadden...

edit2:
Mijn inzending staat overigens sinds 14 januari ook al online: http://hell.student.utwente.nl/files/GoT/PC4/

edit3:
Alvast voortijdig gefeliciteerd, DaCoTa!

[ Voor 41% gewijzigd door Soultaker op 02-06-2009 02:03 ]

[Megamind]

Oh no een error Wel dan de test set online zetten, dan kan ik zien wat er fout is gegaan

[ Voor 26% gewijzigd door Megamind op 02-06-2009 01:53 ]

[.oisyn]

NMe schreef op dinsdag 02 juni 2009 @ 01:47:
.oisyn heeft niks ingestuurd voor zover ik weet

Jawel hoor, alleen na de deadline dus ik deed voor spek en bonen mee

Date: Monday, 12 January, 2009 20:09
To: [e-mail]
Subject: Re: Inzending PRG Contest 4 - .oisyn

[ Voor 21% gewijzigd door .oisyn op 02-06-2009 02:13 ]

[NMe]

.oisyn schreef op dinsdag 02 juni 2009 @ 02:11:
[...]

Jawel hoor, alleen na de deadline dus ik deed voor spek en bonen mee

[...]

Die is dan ook ofwel niet aangekomen ofwel kwijtgeraakt. Als je hem even forwardt kom je ook gewoon in het lijstje erbij.

edit:

Uiteindelijke testset: http://crew.tweakers.net/Contests/PRG/004/files/speelset.zip
Scorelijst hierboven bevat nu ook die van Soultaker.

[ Voor 18% gewijzigd door NMe op 02-06-2009 02:32 ]

[Soultaker]

\o/ Thanks!

Nog aardig close in de top. Misschien had ik toch mijn parallellisatiecode moeten fixen.

Uit zichzelf gestopt, maar mist toch twee moves?

Dit was min of meer by design geloof ik, maar waarom precies weet ik niet meer...

[ Voor 41% gewijzigd door Soultaker op 02-06-2009 02:52 ]

[.oisyn]

Sent

[NMe]

Ran & validated.

[compufreak88]

Valt me nog mee dat ik iets geldigs eruit heb kunnen halen. Ik meen me te herinneren dat ik zelf nog allerlei rare dingen eruit kreeg. Ik heb hem pas op het laatst afgemaakt, een veel tijd om een leuk algorithme te bedenken had ik niet.

[Pete]

Waarom is mijn code met de client vm gerund en zo weinig memory?

[NMe]

Omdat er maar 2GB geheugen in mijn systeem zit en hij bij hogere getallen niet eens wilde draaien. Daarnaast zijn de andere Java-inzendingen ook met die settings gedraaid.

De server-JVM kreeg ik helaas niet aan de praat en ik wilde op zijn minst wat scores genereren. Ik wil nog wel eens kijken of ik de server werkend krijg en je code nog eens runnen.

[Woy]

Pete schreef op dinsdag 02 juni 2009 @ 06:45:
Waarom is mijn code met de client vm gerund en zo weinig memory?

Zo weinig memory? Ik vind 1GB anders best aardig. Waarom het niet als server gerund is weet ik niet.

edit:

Mmm. er schijnt ook een F5 op mijn keyboard te zitten

[ Voor 12% gewijzigd door Woy op 02-06-2009 08:56 ]

[Pete]

Woy schreef op dinsdag 02 juni 2009 @ 08:55:
[...]

Zo weinig memmory? Ik vind 1GB anders best aardig. Waarom het niet als server gerund is weet ik niet.

edit:

Mmm. er schijnt ook een F5 op mijn keyboard te zitten

Het probleem is dat de java VM nu constant bezig is memory op te schonen, terwijl het zich bezig moet houden met rekenen
Een bovengemiddelde consumenten pc heeft tegenwoordig toch wel 4Gb geheugen (en helemaal de windows-pc van een programmeur). Misschien kan geprobeerd worden te runnen met 1500Mb.

[Matis]

Pete schreef op dinsdag 02 juni 2009 @ 08:58:
Het probleem is dat de java VM nu constant bezig is memory op te schonen, terwijl het zich bezig moet houden met rekenen
Een bovengemiddelde consumenten pc heeft tegenwoordig toch wel 4Gb geheugen (en helemaal de windows-pc van een programmeur). Misschien kan geprobeerd worden te runnen met 1500Mb.

Misschien ben ik mr. Obvious, maar waarom zou je in g*dsnaam 1,5 GB nodig hebben voor een applicatie die wat text bestandjes inleest en er weer een aantal uitpoept?

[Woy]

Matis schreef op dinsdag 02 juni 2009 @ 09:10:
[...]
Misschien ben ik mr. Obvious, maar waarom zou je in g*dsnaam 1,5 GB nodig hebben voor een applicatie die wat text bestandjes inleest en er weer een aantal uitpoept?

Dat is nogal kort door de bocht, ik kan me best voorstellen dat je voor het verwerken flink wat geheugen wilt gebruiken, want als je de complete zoekboom in je geheugen houdt, dan loopt het snel op.

Maar 1GB vind ik nog niet zo'n gekke limiet, tuurlijk hebben veel PC's tegenwoordig 4GB of nog wel meer, maar er zijn bijna geen applicaties die dat ook volledig claimen.

Maar het is wel een idee om voor de volgende contest wat beter duidelijk te hebben op wat voor machine er gedraaid gaat worden, maar het blijft toch lastig omdat je met zoveel verschillende talen/platformen werkt die allemaal weer anders met de resources om gaan.

[Matis]

Woy schreef op dinsdag 02 juni 2009 @ 09:22:
[...]

Dat is nogal kort door de bocht, ik kan me best voorstellen dat je voor het verwerken flink wat geheugen wilt gebruiken, want als je de complete zoekboom in je geheugen houdt, dan loopt het snel op.

Natuurlijk, maar 1GB aan ruwe data vind ik toch wel zorgelijk. Ik heb niet actief meegedaan aan de contest, dus eigenlijk niet echt recht van spreken, maar misschien moet er in het vervolg een appendix worden toegevoegd met een aantal regels om deze discussie tegen te gaan (no offense Pete).

[Pete]

Matis schreef op dinsdag 02 juni 2009 @ 09:10:
[...]


Misschien ben ik mr. Obvious, maar waarom zou je in g*dsnaam 1,5 GB nodig hebben voor een applicatie die wat text bestandjes inleest en er weer een aantal uitpoept?

Misschien zou je even na kunnen denken hoe je het probleem oplost. Aangezien er als er elke zet 10 mogelijkheden zijn je in totaal 10^100.000 mogelijke oplossingen zijn. Ik ga op een slimme manier door die zetten, maar ik moet er continue wel een hoop onthouden om de beste 'route' te kunnen vinden.

Uiteraard heb jij een oplossing die max 100 kb geheugen nodig heeft, is het niet?