sciencetalk

Pro. Al zal mijn essentiële bijdrage dan volgende twee weken geleverd moeten worden wegens vakantie

Ik ben anders wel voorstander van SVN via http://code.google.com

Hmm, kan er dan misschien iemand controleren of het wel toegelaten is om een WSF-team samen te stellen? Of anders gaan we een SVN-repository moeten gebruiken die niet vrij toegankelijk is, zoals XP-Dev.com

Wat we dan nog moeten afspreken is een taal en een platform.

Ik ben persoonlijk voor Java-Netbeans, omdat je de run-knop daar kunt instellen zodat je de bot probeert, al dan niet op de beta-server. Maar Eclipse is ook prima.

Edit: ik ben dus ook voor, natuurlijk

Netbeans is zeker ok voor mij, mijn IDE bij voorkeur

Question: Can we make teams?

Answer: Yes, but say so in the "bio" field when you create the team's account.

Dat is dus al meteen geen probleem.

Ik heb steeds eclipse gebruikt en ben er zeer tevreden van. Onlangs ben ik beginnen werken met Netbeans, en dat is zomogelijk nog beter! Wat dat betreft zitten we dus op dezelfde lijn.

Houden we het dan op google code? En meteen een domme vraag (ik heb geen ervaring in werken in team aan een stuk code): waar compilet men de code? Met andere woorden, de code is wel shared, maar moet je steeds de bestanden weer downloaden om ze dan lokaal uit te voeren?

Houden we het dan op google code? En meteen een domme vraag (ik heb geen ervaring in werken in team aan een stuk code): waar compilet men de code? Met andere woorden, de code is wel shared, maar moet je steeds de bestanden weer downloaden om ze dan lokaal uit te voeren?

Ja, iedere keer als je een stuk van je code (goed) werkende krijgt, probeer je die te committen. Op dat moment gaat SVN de stukken code samenvoegen met de code die online stond. Als de versie online al verandert is, ga je eerst je code moeten updaten (SVN voegt vrij intelligent de verschillende versies samen) vooraleer weer te kunnen committen. Op die manier is er steeds slechts 1 versie, waar je met verschillende mensen tegelijk aan kunt werken.

Als ik dan de volgende dag wil verder doen, update ik eerst naar de laatste versie, programmeer wat, probeer een compileerbaar geheel te maken en commit.

Het ALLERBELANGRIJKSTE is dat je NOOIT code commit die niet compileert eigenlijk is het niet zo erg, maar het is erg frustrerend voor andere programmeurs die eerst moeten uitdokteren dat het aan een slechte SVN-versie ligt.

Je doet dus alles lokaal, SVN is enkel een methode om bestanden aan elkaar door te spelen, zoals sommige mensen e-mail gebruiken om aan een groepswerk te werken. Je download de laatste versie, werkt er wat aan, en commit dan weer.

Belangrijk in dit geheel is dus dat verschillende functionaliteit ook in verschillende klassen terechtkomt, dit vereenvoudigt het samenvoegen achteraf. Ook wordt commentaar schrijven en duidelijke benaming gebruiken voor variabele belangrijk. En aan de conventies inzake naamgeving houden natuurlijk ook

Ah, ok, bedankt.

En wat zijn de voordelen tegenover bijvoorbeeld een dropbox (wuala) die je sharet?

Dan werk je steeds lokaal. En iedereen blijft gesynct?

Dan werk je steeds lokaal. En iedereen blijft gesynct?

1) als jij iets savet om te kunnen compilen, en het compilet niet, dan gaat hij bij mij meteen updaten, ook al vraag ik daar niet naar. Als ik dan ook bezig was, dan maken we steeds elkaars versie kapot. Met dropbox kun je onmogelijk tegelijk werken. Bij SVN commit je slechts wanneer hij werkt en het af is.

2) SVN kan intelligent 'mergen'. Als jij een functie toevoegt aan een klasse, en ik heb tegelijk een andere functie toegevoegd aan een klasse, dan gaat SVN die mergen tot 1 klasse met 2 nieuwe functies. Maar als jij iets verandert hebt aan een regel code, en ik ook in diezelfde regel, dan gaat SVN je waarschuwen en alles manueel laten oplossen, zodat de code MOET werken. Dropbox gaat altijd maar 1 versie houden.

Dropbox is eigenlijk een erg dom protocol. Hij update, ook als het totaal niet nodig is. Hij doet niet aan mergen, altijd maar 1 versie, je kunt niet terug gaan in de tijd, je kunt niet een file 'opeisen' zodat enkel jij die nog mag aanpassen, je kunt niet lokaal werken totdat het af is en dan pas doorsturen...

Het enige goede aan dropbox, is dat ze een interface bedacht hebben die iedere leek meteen begrijpt. Ze hebben er wel heel veel moeten voor opofferen.

Okay, erg duidelijk, bedankt!

Om nu binnenkort aan de slag te gaan: we kunnen nu misschien een beetje concreter beginnen denken:

• svn: Google code, iedereen akkoord?
• Taal: iedereen akkoord?
• IDE: Netbeans, iedereen akkoord?

Andere praktische zaken:

• Wie zet de svn op?
• Wie doet er mee?
• Praktische afspraken?

Ik veronderstel dat er eerst zal gebrainstormd worden over de grote lijn van onze strategie, en dat die nadien zullen verfijnen via de svn.

In physics I trust schreef:

• Wie zet de svn op?
• Wie doet er mee?
• Praktische afspraken?

Ik ga pas dingen beginnen doen, na mijn laatste examen, vrijdag.

Ik stel voor dat iedereen flexibel is in wat hij doet. Schrijf boven iedere functie commentaar die heel nauwkeurig beschrijft wat die functie doet. Anderen blijven van de functie af, tenzij in samenspraak of om een bug te verbeteren die ervoor zorgde dat hij niet deed wat er beschreven was. Vermeld ook je naam bij de commentaar, ook als je iets aangepast hebt. Als je de functionaliteit van je eigen functie wil aanpassen, kijk dan eerst eens of niemand anders hem al gebruikt.

I.p.v. functie zou hier ook klasse kunnen staan, zoals in vele projecten, maar dat lijkt me niet zo opportuun voor een hobby-project, waar de fun net ligt in het experimenteren.

Ik veronderstel dat er eerst zal gebrainstormd worden over de grote lijn van onze strategie, en dat die nadien zullen verfijnen via de svn.

Allright: 1e voorstel

We hebben nodig:

• een klasse die een map bijhoudt van wat gekend is, wat ge-extrapoleerd kan worden, wat we verwachten te bereiken en wat we niet weten.
• een klasse die de maps bijhoudt uit het verleden en ook van de geplande toekomst.
• een klasse die de tijd bijhoudt over hoe lang de berekeningen al lopen
• een klasse die de debug en output regelt, die we dan gemakkelijk kunnen afzetten op hun server.

Die klassen zorgen voor de informatie-management. Zo is alle noodzakelijke informatie altijd beschikbaar.

Daarbuiten hebben we iets nodig dat de input in die informatiestructuur giet en er vervolgens uiteindelijk de output teruggeeft.

Hiervoor stel ik een laagjesstructuur voor. Dit is gemakkelijker te vatten aangezien je steeds enkel met de laag erboven en de laag eronder moet rekening houden, ook zijn aanpassingen steeds correct, zolang je je maar aan de interface naar de aangrenzende lagen houdt.

Een concreet voorbeeld:

1. De input komt bovenaan binnen en wordt verwerkt,
2. daarna wordt de strategie bepaalt a.d.h.v. de oude strategie en de nieuwe informatie,
3. daarna worden specifieke plannen gemaakt a.d.h.v. de strategie en toegevoegd aan de plannenpool,
4. die plannen worden geselecteerd en gefilterd en worden plannen in uitvoering,
5. die plannen in uitvoering worden opgedeeld in trajecten per mier
6. vervolgens worden de trajecten die uitgevoerd worden ingepland in de informatie-management,
7. daarna worden de trajecten omgezet in concrete bewegingen voor de volgende beurt,
8. en die worden op hun beurt de output.

Qua strategie vraag ik me een aantal dingen af,

1. zo vraag ik me af of je geen constructies kunt bedenken die gegarandeerd onsterfelijk zijn.
2. Of nog beter, constructies waarmee je een doorgang volledig kunt blokkeren.
3. kan het opportuun zijn om voedsel niet direct te nemen, maar om het op te sparen om dan met een groep mieren water over te steken
4. Kun je beter een gebied controleren, of met een leger op rooftocht gaan? Of een combinatie van beide?

Ik denk dat dit spel wel te realiseren is met een evaluatie functie die de winstkans geeft voor een welbepaalde positie. Deze functie zou met een soort van self-play en gewichten kunnen opgevat worden. (Ik zou geen NN gebruiken maar strategieën inbouwen en deze koppelen met gewichten.)

Ja ik ben het met bovenstaande zaken eens. Ik zat ook met het idee om een gebied te controleren door doorgangen af te bakenen (als je een 'muur' van mieren bouwt, worden vijanden volgens mij geëlimineerd voordat ze een bres kunnen slaan. Binnen het afgebakende gebied kunnen een vast aantal mieren het gebied afscannen naar voedsel (ik zou hiervoor werken met een 'ants-density') en als die dichtheid verhoogt, zou ik de 'muren' laten opschuiven.Dat heeft het voordeel dat je niet voortdurend mieren verliest aan confrontaties met andere kolonnes.

Eens een bepaald aantal mieren bereikt, kunnen we overgaan op aggresive mode, waarbij een bepaald percentage wordt uitgestuurd als leger, en dan (door bijeen te blijven), wel vernieling zaaien in de vijandelijke gelederen, maar zelf minimaal beschadigd worden. Door het vaste gebied (home centre) dat je bezit, heb je een plek waar je rustig nieuwe miertjes kweekt, en het leger zal natuurlijk zelfversterkend werken: als het voedsel tegenkomt, wordt het leger weer versterkt. Towards victory ...

Ik had ook al even gedacht aan enkele strategieen

Mijn eerste idee was ook om een 'wolk' van mieren te hebben die een bepaalde dichtheid aanhoudt.

Nu als je een wolk maakt, is het eigenlijk niet nodig om in het midden veel mieren te hebben, aangezien daar geen tegenstanders komen.

Langs buiten moet de dichtheid dan weer groter zijn (zoals de muur waar trust van spreekt)

Nu dacht ik, om dit eenvoudig te implementeren doen we het volgende voor elke mier:

1: Tellen hoeveel miertjes van je eigen soort in een bepaalde radius zitten

2: Eigen miertjes ten noorden, oosten, zuiden, westen (elk apart) van elke mier tellen. Stap 1 en 2 kunnen natuurlijk in keer gebeuren.

3: Als er minder miertjes dan het optimale in de radius zitten, dan gaat de mier naar de kant (NOZW) waar meest miertjes zitten, dus richting de kolonie toe. Anderzijds als er meer dan het optimale binnen de radius zitten gaat de mier naar de kant (NOZW) waar minst miertjes zitten, dus uitspreiden.

Op deze manier krijg je automatisch een zichzelf uitspreidende wolk met verstevigde randen, met zeer weinig rekenkracht.

Dit kan misschien als basis dienen. Het enige waar we even mee moeten experimenteren is de radius en het optimale aantal.

Natuurlijk zou dit enkel de basis zijn dus wat we nog kunnen implementeren:

- Een leger afsplitsen om een kleine kolonie de genadeslag te geven en zo zelf snel terrein bij te krijgen

- Intelligent gebruik maken van de barrieres

- Hoe reageren op een vreemde mier die in de buurt komt?

- Slim voedsel zoeken

Maar dus vooral de vraag: Begrijpen jullie wat ik bedoel met mijn basisstratiegie, en wat is de mening erover?

EDIT: Ik denk zelf dat dit wel een goede strategie is, maar er moet moet er wel nog een 'opstartstrategie' komen, wanneer er helemaal nog niet van een wolk gesproken kan worden. Dan is het vooral van belang om zich snel te vermenigvuldigen, zonder verstevigde randen, omdat de tegenstanders dan ook nog niet in de buurt zijn.

In grote lijnen ga ik akkoord met je ideeën.

Wat betreft opstart heb je zeker gelijk en volgens mij kan je dan niet beter doen dan - telkens je een nieuwe mier verwerft ze in tegengestelde richtingen sturen. Dus: de orspronkelijk gaat rechtdoor, en de nieuwe 90 graden naar rechts. Komt deze dan voedsel tegen, hetzelfde. Op die manier krijg je ook dat ze na een keer of vier weer tezamen komen, en dan kan je aan de slag met een 'wolk'.

En er moet een intelligente manier zijn om grillige randjes te vermijden (verdwaald geraken voorkomen).

Ik denk dat dit spel wel te realiseren is met een evaluatie functie die de winstkans geeft voor een welbepaalde positie. Deze functie zou met een soort van self-play en gewichten kunnen opgevat worden. (Ik zou geen NN gebruiken maar strategieën inbouwen en deze koppelen met gewichten.)

Dus machine learning? Het enige probleem dat ik zie, is dat je bij 100 mieren 9^100 mogelijke zetten moet evalueren. Tenzij je alle mieren afzonderlijk laat denken, en dan heb je er nog maar 9x100, maar het lijkt me niet dat je zo strategie kunt implementeren of leren. Je moet in ieder geval wel zwaar in de boom snoeien, doordat je N mieren tegelijk moet verplaatsen. (i.t.t. bijvoorbeeld schaken), hoe zou je dat dan doen?

Ook: hoe ga je om met de onvolledige informatie?

venra schreef:Nu dacht ik, om dit eenvoudig te implementeren doen we het volgende voor elke mier:

1: Tellen hoeveel miertjes van je eigen soort in een bepaalde radius zitten

2: Eigen miertjes ten noorden, oosten, zuiden, westen (elk apart) van elke mier tellen. Stap 1 en 2 kunnen natuurlijk in keer gebeuren.

3: Als er minder miertjes dan het optimale in de radius zitten, dan gaat de mier naar de kant (NOZW) waar meest miertjes zitten, dus richting de kolonie toe. Anderzijds als er meer dan het optimale binnen de radius zitten gaat de mier naar de kant (NOZW) waar minst miertjes zitten, dus uitspreiden.

Op deze manier krijg je automatisch een zichzelf uitspreidende wolk met verstevigde randen, met zeer weinig rekenkracht.

Ik denk niet dat je hiermee een uitspreidende wolk met dikke randen krijgt Je krijgt waarschijnlijk wel een dikke structuur, maar of die nu een ring is, een acht, een kruis of iets anders kun je niet weten. Je kunt zelfs niet garanderen dat het 1 structuur blijft.

Ik denk niet dat je hiermee een uitspreidende wolk met dikke randen krijgt Je krijgt waarschijnlijk wel een dikke structuur, maar of die nu een ring is, een acht, een kruis of iets anders kun je niet weten. Je kunt zelfs niet garanderen dat het 1 structuur blijft.

- De dikke randen krijg je zeker, want een mier aan de rand heeft de neiging om weer naar binnen te gaan, tot de dichtheid binnenin groot genoeg is.

- Oke, het zal niet steeds cirkelvormig zijn (al is daar de grootste kans op), maar dat maakt helemaal niet uit voor het doel van het spel. Het doel is om zo snel mogelijk uit te spreiden, maar niet te snel dat je je veroverd veld kan beschermen.

- De wolk zal nooit spontaan een 8 vormen of splitsen (als je deze strategie start van bvb >30 mieren). Stel dat ze toch splitst doordat een tegenstander aanvalt, zal de methode er automatisch voor zorgen dat de twee wolken een afzonderlijk leven gaan leiden. Eventueel kan dan een methode ingebouwd worden dat de wolken op grote schaal weer naar elkaar toe gaan.

Het zijn maar ideeen he natuurlijk