Ik vermoed dat het wel genoeg is, zijn erg indrukwekkende score's en tijden! Maar goed we hebben nog een maand, ik hoop dat ik nog een goed idee krijg.Marcj schreef op woensdag 21 maart 2007 @ 20:29:
Hmm, ik heb nog wel zitten proberen te veranderen qua sortering, maar dit lijkt niet erg veel invloed te hebben. Ik heb wel bij toeval een manier ontdekt om de eerste grid van de eerste testset met een score van 1952 te halen, maar helaas is de score over de hele set juist weer minder (andere grids worden dus negatief beinvloed). Dus ik denk dat ik het eerst zo laat, veel meer kan ik ook niet bedenken...
Die foutmelding is de standaard melding, ondertussen wordt naar mij een e-mail gestuurd met de details.KoW schreef op donderdag 22 maart 2007 @ 12:18:
Maar, de online validator geeft een vreemde melding nadat hij wel eerst zijn werk heeft gedaan.
Blijkbaar was de sql-server niet goed bereikbaar (statistieken), dit is 2x voorgekomen.
Bezoek eens een willekeurige pagina
Zo, hehe, mijn eerste resultaat (testset 1):
Programma output:
Score:
Ik heb nog wel een aantal ideetjes om het algo nog beter te krijgen, die ga ik de komende tijd maar eens even uitproberen
.
Programma output:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
| Loading words.txt into grid objects... Validating words.txt... words.txt validated. (0 ms) Loading finished successfully in 15 milliseconds. Finished processing. Summary: Grid 01: Word count : 487 Total processing time : 1375 ms Grid 02: Word count : 578 Total processing time : 1766 ms Grid 03: Word count : 560 Total processing time : 1532 ms Grid 04: Word count : 429 Total processing time : 1218 ms Grid 05: Word count : 487 Total processing time : 1281 ms Grid 06: Word count : 731 Total processing time : 1938 ms This program spent 2234 ms of your CPU's valueable time :P |
Score:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
| BLOK 1 Compleet Aantal woorden: 487 Aantal letters (bron): 3231 Aantal letters (grid): 2201 Percentage bespaard: 31.88 Percentage over: 68.12 BLOK 2 Compleet Aantal woorden: 578 Aantal letters (bron): 3779 Aantal letters (grid): 2514 Percentage bespaard: 33.47 Percentage over: 66.53 BLOK 3 Compleet Aantal woorden: 560 Aantal letters (bron): 3661 Aantal letters (grid): 2446 Percentage bespaard: 33.19 Percentage over: 66.81 BLOK 4 Compleet Aantal woorden: 429 Aantal letters (bron): 2771 Aantal letters (grid): 1871 Percentage bespaard: 32.48 Percentage over: 67.52 BLOK 5 Compleet Aantal woorden: 487 Aantal letters (bron): 3178 Aantal letters (grid): 2131 Percentage bespaard: 32.95 Percentage over: 67.05 BLOK 6 Compleet Aantal woorden: 731 Aantal letters (bron): 4768 Aantal letters (grid): 3178 Percentage bespaard: 33.35 Percentage over: 66.65 |
Ik heb nog wel een aantal ideetjes om het algo nog beter te krijgen, die ga ik de komende tijd maar eens even uitproberen
Stel niet uit tot morgen wat je vandaag nog tot morgen kunt uitstellen...
Vette contest...
goed bezig allemaal...
goed bezig allemaal...
Klus page: http://klusthuis.blogspot.com
Doe je ook mee?
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
offtopic:
Gezien zijn verdere posts
Gezien zijn verdere posts
* KoW heeft een nieuw ideetje om het een en ander volledig over een andere boeg te gooien.
Het zal wel ten koste gaan van de verwerkings tijd, maar ik geloof dat het wel een lagere eindscore geeft.
Inzetten op iig tijd lijkt me lastig met de wel erg snelle tijden die ik hier voorbij zie komen.
mja ik heb ook opgegeven op tijd, en ga me vooral richten op puntjes. Al wil daar ook niet super veel schot in komen (weinig tijd). Heb ook hele project omgezet naar C ipv C++
Het wordt een beetje stil hier? Zijn er nog mensen met leuke resultaten?
(ben zelf bezig, maar heb niet veel tijd om er mee bezig te zijn).
(ben zelf bezig, maar heb niet veel tijd om er mee bezig te zijn).
Ik ben er al een tijdje niet meer mee bezig geweest, maar ik vind m'n programma wel zo'n beetje af. Moet alleen nog de code een beetje opschonen...
Verder ben ik wel benieuwd hoeveel mensen uiteindelijk gaan meedoen, want zo te zien zijn dat er nu al een stuk meer dan de vorige keer.
Verder ben ik wel benieuwd hoeveel mensen uiteindelijk gaan meedoen, want zo te zien zijn dat er nu al een stuk meer dan de vorige keer.
Ja ben ook af en toe bezig, maar ik kom nog niet in de buurt van goede resultaten. En nog weinig inspiratie om het te verbeteren eerlijk gezegd...
Ik heb een werkende stand, en de code aardig gerefactored. De laatste tijd geen tijd meer gehad en weet ook niet of ik er nog aan toe kom.
Mijn code is niet erg slim, maar ik zal hem zeker weten inleveren.
Mijn code is niet erg slim, maar ik zal hem zeker weten inleveren.
Dat is wat je bij elk project ziet, niet alleen hier. Ergens in het begin wordt er actief en enthousiast aan gewerkt, om vervolgens een tijdje in de vergetelheid te raken. Uiteindelijk komt er vlak voor de deadline wel weer een opleving, net als bij de vorige contest.compufreak88 schreef op maandag 26 maart 2007 @ 12:01:
Het wordt een beetje stil hier?
Wat dat betreft ben ik blij dat de limiet in tijd deze keer opgeschoven is van 2 naar slechts 1 uur. Er waren de vorige keer maar 8 inzendingen, maar er ging toch aardig wat tijd zitten in het runnen van de zooi.Marcj schreef op maandag 26 maart 2007 @ 12:07:
Verder ben ik wel benieuwd hoeveel mensen uiteindelijk gaan meedoen, want zo te zien zijn dat er nu al een stuk meer dan de vorige keer.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Oh, de testmachine is dus geen dual quadcore waar alle 8 de inzendingen parallel op draaien?-NMe- schreef op maandag 26 maart 2007 @ 12:59:
Er waren de vorige keer maar 8 inzendingen, maar er ging toch aardig wat tijd zitten in het runnen van de zooi.
hehe.
Dan hoop ik dat die andere 7 inzendingen gaan vechten om de CPU zodat mijn inzending rustig zijn resultaten kan berekenen
Vorige week had ik geen tijd ivm toneelvoorstellingen en de voorbereiding daarvoor. Deze week nog 2 voorstellingen. Daarna heb ik weer iets meer tijd.
Dan hoop ik dat die andere 7 inzendingen gaan vechten om de CPU zodat mijn inzending rustig zijn resultaten kan berekenen
Vorige week had ik geen tijd ivm toneelvoorstellingen en de voorbereiding daarvoor. Deze week nog 2 voorstellingen. Daarna heb ik weer iets meer tijd.
Hee een contest. Interessant. 
Ik kreeg bij het lezen van de opdracht gelijk een stroom aan ideeën. Eerst maar eens een sluitend algoritme uitschrijven daarna eens kijken of ik nog tijd heb om het in programmacode te stoppen. Nog geen idee in welke taal ik het zal gaan maken, die keuze komt later wel.
Het is grappig dat iedereen zo gericht is op de grid als vorm. Volgens mij kun je dit probleem veel beter doorrekenen als je redeneert in verbanden dan in een gefixeerd grid.
Nou nog zien dat ik mezelf lang genoeg gemotiveerd houd om de code ook uit te schrijven...
Ik kreeg bij het lezen van de opdracht gelijk een stroom aan ideeën. Eerst maar eens een sluitend algoritme uitschrijven daarna eens kijken of ik nog tijd heb om het in programmacode te stoppen. Nog geen idee in welke taal ik het zal gaan maken, die keuze komt later wel.
Het is grappig dat iedereen zo gericht is op de grid als vorm. Volgens mij kun je dit probleem veel beter doorrekenen als je redeneert in verbanden dan in een gefixeerd grid.
Nou nog zien dat ik mezelf lang genoeg gemotiveerd houd om de code ook uit te schrijven...
Mja, ik ken het probleem...DaCoTa schreef op maandag 26 maart 2007 @ 12:08:
Ja ben ook af en toe bezig, maar ik kom nog niet in de buurt van goede resultaten. En nog weinig inspiratie om het te verbeteren eerlijk gezegd...
One ring to rule them all, one ring to find them, one ring to bring them all, and in darkness bind them...
Ik ben maar helemaal opnieuw begonnen in C#. Mijn Delphi programma werkte opzich wel, maar ik vond het een rommeltje worden. Ik ben er toch achter gekomen dat delphi te rommelig is voor mij. C# ligt me veel beter vanwege de syntax die veel op die van php en java lijkt.
(Zeg ik nu al
, programmeer er pas 2 uurtjes ofzo in.)
Maar buiten dat om heb ik ook nog een vraagje aan de c# experts hier. Ik ben dus de grids aan het splitten en ik heb naar mijn inzicht een logisch stukkie code getypt. Maar ik krijg het niet werkend, ik heb al een half uur gedebugt. Hij blijft hierbij oneindig dezelfde grid toevoegen.
(i=487)
edit: (variabele i is bij de start 0 !!! Was ik vergeten te vermelden)
Maar buiten dat om heb ik ook nog een vraagje aan de c# experts hier. Ik ben dus de grids aan het splitten en ik heb naar mijn inzicht een logisch stukkie code getypt. Maar ik krijg het niet werkend, ik heb al een half uur gedebugt. Hij blijft hierbij oneindig dezelfde grid toevoegen.
C#:
1
2
3
4
5
6
7
8
9
10
11
| // Ga opzoek naar split plekken while(Grid.IndexOf("", i) != -1) { // Voeg een Grid toe aan de lijst ListOfGrids.Add( Grid.GetRange(i, Grid.IndexOf("", i)) ); // Debug nonsens ShowGridStats((ArrayList) ListOfGrids[ListOfGrids.Count -1], false, "Grid " + Convert.ToString(ListOfGrids.Count) ); i = Grid.IndexOf("", i); } |
edit: (variabele i is bij de start 0 !!! Was ik vergeten te vermelden)
[ Voor 3% gewijzigd door Aloys op 26-03-2007 21:18 ]
IndexOf("", 0) zal altijd 0 opleveren volgens mij, omdat de lege string overal past. Hierdoor voeg je steeds lege strings to en blijft i nog steeds 0, toch? Ik snap het stukje code niet echt, omdat ik niet weet wat voor type alles is...
Sja is inderdaad mischien een beetje lastig zo, ff opsomming:
- ListOfGrids -> ArrayList
- Grids -> ArrayList
- i -> int
De functie indexOf zit zo -> indexOf(SearchString, startPosition); Verder is het wel zo wanneer ik onderaan bij "i= blabla" +1 toevoeg wel verder kom, maar dan is het bij de 2e of 3x een keiharde error. (Buiten bereik van array) En ik zou bij 6 grids moeten komen.
- ListOfGrids -> ArrayList
- Grids -> ArrayList
- i -> int
De functie indexOf zit zo -> indexOf(SearchString, startPosition); Verder is het wel zo wanneer ik onderaan bij "i= blabla" +1 toevoeg wel verder kom, maar dan is het bij de 2e of 3x een keiharde error. (Buiten bereik van array) En ik zou bij 6 grids moeten komen.
http://msdn2.microsoft.co...s.arraylist.getrange.aspx
Zoals je hier kunt lezen moet je bij GetRange() niet de eerste en laatste index opgeven, maar de eerste index en het aantal. Waarschijnlijk kopieert hij nu veel te veel
Zoals je hier kunt lezen moet je bij GetRange() niet de eerste en laatste index opgeven, maar de eerste index en het aantal. Waarschijnlijk kopieert hij nu veel te veel
aha,,,, dat zou het indderdaad zijn. Hij doet 1700 en 2000 ofzo... en er zijn maar 3200 woorden. Ik ga er zo fftjes naar kijken. Bedankt Marcj.
[ Voor 0% gewijzigd door Aloys op 26-03-2007 22:40 . Reden: 1 nulletje schilt toch wel veel (2000) ]
Mijn code om dubbele woorden te verwijderen werkt nu eindelijk
Hier ligt het werk al een weekje stil. Ik heb wel wat ideeen welke kant ik ongeveer op moet, maar meer dan dat nog niet. Helaas heb ik het op het moment nogal druk, maar dat zou eind volgende week ook weer wat minder moeten zijn. Dus dan kan ik weer aan de slag, in eerste instantie dacht ik dat de deadline wel erg ruim was, maar eigenlijk komt het nu toch wel goed uit (zeker omdat de contest lastiger is dan hij in eerste instantie lijkt).
The Flying Dutchman
Mijn code doet er +/- 6 seconden over om de lijst in te laden en te verwerken... Dat vind ik best lang...
Als je nagaat dat het goed en handig plaatsen van de woorden een behoorlijk tijdrovende klus is en je daar maximaal 36 seconden (60*60/99) per grid over mag doen, dan staat dat niet geheel in verhouding, nee.compufreak88 schreef op dinsdag 27 maart 2007 @ 14:11:
Mijn code doet er +/- 6 seconden over om de lijst in te laden en te verwerken... Dat vind ik best lang...
Wat doe je wel allemaal niet met die woorden tijdens het inladen?
@compufreak88: debugmode misschien? das rete traag. bij mij doet VS2005 c++ er iets van 20 secs over om lijst in te lezen en dubbele te verwijderen in debugmode
Wat ik momenteel doe is alle woorden met alle woorden vergelijken, daar zit het waarschijnlijk in, maar ik kon zo geen andere manier vinden om het goed te laten werkenArty_Shock schreef op dinsdag 27 maart 2007 @ 14:33:
[...]
Als je nagaat dat het goed en handig plaatsen van de woorden een behoorlijk tijdrovende klus is en je daar maximaal 36 seconden (60*60/99) per grid over mag doen, dan staat dat niet geheel in verhouding, nee.
Wat doe je wel allemaal niet met die woorden tijdens het inladen?
Ik gebruik python.MiezeL schreef op dinsdag 27 maart 2007 @ 14:34:
@compufreak88: debugmode misschien? das rete traag. bij mij doet VS2005 c++ er iets van 20 secs over om lijst in te lezen en dubbele te verwijderen in debugmode
grid00 grid01 grid02 grid03 grid04 grid05 -------------------------------------------------------- Before: 487 578 560 429 487 732 After: 467 543 536 412 467 701 Processing words: 7047.0 ms
Dit zijn mijn eerste resultaten (de woordenlijsten dan hè, niet de uiteindelijke grid)
[ Voor 16% gewijzigd door compufreak88 op 27-03-2007 15:15 ]
Ik was niet tevreden over de resultaten van het huidige algoritme en aldus heb ik het naar de prullenbak verwezen. Terug achter de tekentafel heb ik een algoritme ontwikkelt dat theoretisch gezien optimaal is (en dat geen pure brute force is
). De implementatie zal wel razend efficiënt moeten zijn, aangezien het een vrij computationeel en geheugenopslorpend is.
Al bij al hoop ik met het nieuwe algoritme betere resultaten te halen. Het moge duidelijk zijn dat m'n algoritme voor de laagste score gaat in de langst mogelijke tijd
. Of ik het algoritme ook daadwerkelijk goed geïmplementeerd krijg is dan weer een andere vraag
.
Al bij al hoop ik met het nieuwe algoritme betere resultaten te halen. Het moge duidelijk zijn dat m'n algoritme voor de laagste score gaat in de langst mogelijke tijd
Performance is a residue of good design.
Verwijderd
Hoewel ik momenteel weinig tijd heb, heb ik toch een eerste poging ondernomen. Hopelijk kan ik nog wat meer tijd vrijmaken voor deze contest want ik heb nog verschillende ideeën om het algoritme beter te maken.
Tot dusver is het niet bijster slim maar het is wel redelijk vlug. In eerste instantie ga ik me nu focussen op de 'intelligentie' hoewel ik nog wel enkele ideeën heb om het sneller te maken. Bij deze de eerste resultaten.
Tot dusver is het niet bijster slim maar het is wel redelijk vlug. In eerste instantie ga ik me nu focussen op de 'intelligentie' hoewel ik nog wel enkele ideeën heb om het sneller te maken. Bij deze de eerste resultaten.
Grid 1 Calc. solution : 0.718 seconds Compressed by : 68.4308% Veri. solution : 0.047 seconds Total time : 0.797 seconds Grid 2 Calc. solution : 0.843 seconds Compressed by : 67.0283% Veri. solution : 0.063 seconds Total time : 0.906 seconds Grid 3 Calc. solution : 0.844 seconds Compressed by : 67.4133% Veri. solution : 0.063 seconds Total time : 0.922 seconds Grid 4 Calc. solution : 0.547 seconds Compressed by : 67.2681% Veri. solution : 0.046 seconds Total time : 0.593 seconds Grid 5 Calc. solution : 0.704 seconds Compressed by : 68.4707% Veri. solution : 0.047 seconds Total time : 0.766 seconds Grid 6 Calc. solution : 1.359 seconds Compressed by : 67.2609% Veri. solution : 0.094 seconds Total time : 1.469 seconds Total time to complete the set: 5.485 seconds.
Compressed by 68%? Hoe krijg je dat voor elkaar?Verwijderd schreef op woensdag 28 maart 2007 @ 00:23:
[..]
Grid 1 Calc. solution : 0.718 seconds Compressed by : 68.4308% Veri. solution : 0.047 seconds Total time : 0.797 seconds [..]
ghehehe dat moet 'to' zijn mag ik hopen
Ik denk stiekem dat 'ie "compressed to" bedoelde in plaats van "compressed by". 
edit:
Of anders vernieuw ik de pagina even voor ik post. [ Voor 28% gewijzigd door NMe op 28-03-2007 09:30 ]
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Verwijderd
Foutje... klopt helemaal, dat mag inderdaad 'to' zijn
. Maar het is een mooi streven wat ik nooit ga halen
.

Ik heb het even laten tellen, maar die van mij doet zo'n 1,8 miljoen iteraties om de woorden te ontdubbelen. Das enorm veel. Kmoet even een manier zien te vinden omdat de reduceren...
Het probleem is, dat als ik items uit de lijst weghaal, hij niet meer goed door de lijst itereert, en er dus items gemist worden.
Het probleem is, dat als ik items uit de lijst weghaal, hij niet meer goed door de lijst itereert, en er dus items gemist worden.
[ Voor 26% gewijzigd door compufreak88 op 28-03-2007 14:22 ]
dudecompufreak88 schreef op woensdag 28 maart 2007 @ 14:12:
Ik heb het even laten tellen, maar die van mij doet zo'n 1,8 miljoen iteraties om de woorden te ontdubbelen. Das enorm veel. Kmoet even een manier zien te vinden omdat de reduceren...
Het probleem is, dat als ik items uit de lijst weghaal, hij niet meer goed door de lijst itereert, en er dus items gemist worden.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| a = start1; b = start2; while(start1 != eind) { while(start2 != eind) { zit start1 in start2? { doe coole dingen } else { start2++; } } start1++; } |
[ Voor 6% gewijzigd door Arjan op 28-03-2007 15:21 ]
oprecht vertrouwen wordt nooit geschaad
Tip: als je lijst met woorden gesorteerd is op lengte, kun je dit doen:
Dit lijkt me toch vrij eenvoudig? (niet getest overigens, ik gebruik zelf geen strings...)
edit: pseudocode dan maar
code:
1
2
3
4
5
6
7
8
9
| functie verwijderDubbellen(Lijst woorden) { for(woord uit woorden) { for(woord2 uit woorden vanaf woord) { if(woord in woord2) { verwijder(woord); probeer volgend woord } } } |
Dit lijkt me toch vrij eenvoudig? (niet getest overigens, ik gebruik zelf geen strings...)
edit: pseudocode dan maar
[ Voor 43% gewijzigd door Marcj op 28-03-2007 15:57 ]
kant en klare code is misschien geen goed plan enzoMarcj schreef op woensdag 28 maart 2007 @ 15:37:
Tip: als je lijst met woorden gesorteerd is op lengte, kun je dit doen:
[...]
Dit lijkt me toch vrij eenvoudig? (niet getest overigens, ik gebruik zelf geen strings...)
oprecht vertrouwen wordt nooit geschaad
Bedankt voor de tips, hier moet ik wel wat mee kunnen 
Het scheelt nu ongeveer de helft aan tijd zoals ik het nu heb, dus het scheelt wel iets...
Vraagje, hoelang doet jullie programma erover om de woorden bij langs te gaan?
Het scheelt nu ongeveer de helft aan tijd zoals ik het nu heb, dus het scheelt wel iets...
Vraagje, hoelang doet jullie programma erover om de woorden bij langs te gaan?
[ Voor 66% gewijzigd door compufreak88 op 28-03-2007 18:10 ]
Als ik alleen words.txt van de eerste testset laat inlezen en dan alle overbodige woorden van de 6 grids (ook in omgekeerde richting) laat verwijderen, doet ie dat in ongeveer 250ms.compufreak88 schreef op woensdag 28 maart 2007 @ 17:04:
...
Vraagje, hoelang doet jullie programma erover om de woorden bij langs te gaan?
Hmm, dan heeft die van mij nog wel even te gaan.
(ben even met een test progje bezig in vb.net 2005 om te kijken of dat sneller gaat).
(ben even met een test progje bezig in vb.net 2005 om te kijken of dat sneller gaat).
wow, heb nu iets geks, ik kwam een bug tegen in me code. teminste, het deed niet wat ik wou dat het deed.
voordat ik aan het echte grid begin, controleer ik ofdat er toevallig ook woorden een beetje lekker in elkaar schuiven. hij doorloopt de woordenlijst, en zoekt twee woorden welke samen het beste samenvoegen. ( teminste dat dacht ik ) en gebruikt dit nieuwe woord voor het grid.
nou zat er in het samen voegen het volgende stuk :
pas nu later bij het schonen zie ik dat ik eigenlijks zoek om een zo lang mogelijk woord.
dit is nu gecorrigeert.
Nou het gekke :
met de buggie code haalde ik uit de eerste lijst, eerste grid, een score van 1992 karakters over.
met de nieuwe wel goed werkende code, haal ik een score van 2002.
en deze verslechtering zie ik bij elk grid.
ik ga nu dus die 'buggie' code terug zetten, maar heb geen idee hoe het kan dat ik nu slechtere scores haal.
voordat ik aan het echte grid begin, controleer ik ofdat er toevallig ook woorden een beetje lekker in elkaar schuiven. hij doorloopt de woordenlijst, en zoekt twee woorden welke samen het beste samenvoegen. ( teminste dat dacht ik ) en gebruikt dit nieuwe woord voor het grid.
nou zat er in het samen voegen het volgende stuk :
code:
1
2
3
4
5
| if (test.Length > best.Length) // als nieuwe woord meer comprimeert { best = test; bestRechts = innerLoop; } |
pas nu later bij het schonen zie ik dat ik eigenlijks zoek om een zo lang mogelijk woord.
dit is nu gecorrigeert.
Nou het gekke :
met de buggie code haalde ik uit de eerste lijst, eerste grid, een score van 1992 karakters over.
met de nieuwe wel goed werkende code, haal ik een score van 2002.
en deze verslechtering zie ik bij elk grid.
ik ga nu dus die 'buggie' code terug zetten, maar heb geen idee hoe het kan dat ik nu slechtere scores haal.
Deze sig is een manueel virus!! Als je dit leest heb je het. Mail dit bericht naar iedereen die je kent, en verwijder alle bestanden van je computer.
Weet je zeker dat de grids die je uit de buggy code haalt ook echt kloppen? (Er staan hier validators ergens in dit topic).
Plus het feit dat ik ideeen heb doorgevoerd die in het ene grid positief van invloed waren en op een ander grid negatief van invloed waren. Je kunt niet van het resultaat van 1 grid uit gaan. 
0 seconden. Ik "ontdubbel" niet. Dat is optimalisatie die pas later wellicht doorvoer om zeker te weten dat het niet van negatieve invloed is op m'n grid.compufreak88 schreef op woensdag 28 maart 2007 @ 17:04:
Vraagje, hoelang doet jullie programma erover om de woorden bij langs te gaan?
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
Ontdubbelen duurt bij mij 15ms per lijst. Ik doe dat wel meteen, want het maakt je lijst korter en is op mijn manier niet van invloed op mijn eindresultaat... maar dat is eerder slecht dan goed
(omdat ik het nog steeds te rechtlijnig doe)
٩(͡๏̯͡๏)۶ ٩(●̮̮̃•̃)۶
zowel de grid met 'buggy' code, als wel de 'correcte' code geven valide grid af.
en ik zie deze toename bij alle grids.
en als ik de hele compressie slag weglaat, dan heb ik nog weer meer karakers in me grid zitten (2023)
en ik zie deze toename bij alle grids.
en als ik de hele compressie slag weglaat, dan heb ik nog weer meer karakers in me grid zitten (2023)
Deze sig is een manueel virus!! Als je dit leest heb je het. Mail dit bericht naar iedereen die je kent, en verwijder alle bestanden van je computer.
Zelfs in vb.net duurt het bij mij nog zo'n 1700 ms... Ik heb eigenlijk ook niet zo veel ervaring met dit soort dingen programmeren. Ben benieuwd naar hoe jullie het hebben opgelost.
draai je dan in debug? want dat is altijd mega traag. moet je ff release bouwen en die runnen
Scheelt maar iets van 200 msMiezeL schreef op donderdag 29 maart 2007 @ 12:22:
draai je dan in debug? want dat is altijd mega traag. moet je ff release bouwen en die runnen
* KoW moet weer even overnieuw gaan beginnen.
Mocht iemand nog een laptop kopen met een mapje GoT contest er op, dan is die van mij.
En ja, de backups op mijn USB harddisks zijn ook pleitte, net als de rest van m'n spullen
Aangezien er nog meer klussen op die laptop stonden weet ik niet zeker of ik nog mee gaa doen.
Die moeten namelijk ook opnieuw worden opgezet.
Mocht iemand nog een laptop kopen met een mapje GoT contest er op, dan is die van mij.
En ja, de backups op mijn USB harddisks zijn ook pleitte, net als de rest van m'n spullen
Aangezien er nog meer klussen op die laptop stonden weet ik niet zeker of ik nog mee gaa doen.
Die moeten namelijk ook opnieuw worden opgezet.
Alles gestolen?? Dat is balen zeg
.. veel succes met opnieuw programmeren. Hopelijk is er nog tijd genoeg (al weet ik niet hoeveel werk er op stond natuurlijk).
Ik ga ook een poging wagen
I see red pixels.
Ik volg nu het vak OOP. Datastructuur verzinnen, bestandje inlezen, excepties afhandelen... allemaal een hele goede oefening voor het tentamen!
Ik heb vorig weekend al wat zitten prutsen en vandaag heeft hij op een complete testset kunnen kouwen. Mijn resultaat tot nu toe:
Ik heb nog wat zitten denken over de datastructuur van het grid en volgens mij moet hij nog een heul stuk sneller kunnen.
Deze tijden zijn trouwens op een oude 2,4Ghz Celeron.
Ik heb vorig weekend al wat zitten prutsen en vandaag heeft hij op een complete testset kunnen kouwen. Mijn resultaat tot nu toe:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| wilco@Carl:~/workspace/KruisWoord> time java KruisWoord grid01.txt: Aantal letters : 3231 Gebruikt aantal letters : 2181 Percentage van origineel: 67.5 grid02.txt: Aantal letters : 3779 Gebruikt aantal letters : 2490 Percentage van origineel: 65.89 grid03.txt: Aantal letters : 3661 Gebruikt aantal letters : 2438 Percentage van origineel: 66.59 grid04.txt: Aantal letters : 2771 Gebruikt aantal letters : 1855 Percentage van origineel: 66.94 grid05.txt: Aantal letters : 3178 Gebruikt aantal letters : 2132 Percentage van origineel: 67.09 grid06.txt: Aantal letters : 4760 Gebruikt aantal letters : 3129 Percentage van origineel: 65.74 real 4m3.516s user 3m37.086s sys 0m0.740s |
Ik heb nog wat zitten denken over de datastructuur van het grid en volgens mij moet hij nog een heul stuk sneller kunnen.
Verwijderd
Bij mijn eerste opzet kwam ik met grid01 met geen mogelijkheid onder de 2011. Opzet nr 2 heeft als eerste resultaat (met dank aan EdwinG voor het gebruik van je validator)
De benodigde rekentijd is circa 10 seconden (AMD 4400+ X2), maar er zit een hele berg asserts in, dus dat kan wel omlaag naar een seconde of 2.
Overigens denk ik de resterende 34 seconden hard nodig te hebben om in de buurt van die m.i. wel heel erg knappe 1952 van Marcj te komen - als ik dat al haal...
Voor de liefhebber:
code:
1
2
3
4
5
| Aantal woorden: 487 Aantal letters (bron): 3231 Aantal letters (grid): 1999 Percentage bespaard: 38.13 Percentage over: 61.87 |
De benodigde rekentijd is circa 10 seconden (AMD 4400+ X2), maar er zit een hele berg asserts in, dus dat kan wel omlaag naar een seconde of 2.
Overigens denk ik de resterende 34 seconden hard nodig te hebben om in de buurt van die m.i. wel heel erg knappe 1952 van Marcj te komen - als ik dat al haal...
Voor de liefhebber:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
| <grid01> n p e ea k js gimmickirts laatsteveni g nbosduifl on n rueffiksnuffen l netjirkalvjilgs h uitrokenetnakmobskes spitseneiurkpoolruud voorraaduogfotsilucoloristeppeneimartskrebbagy w redruelkiel mtm c j kpimpelen kvieslooizuurkastemmenn m hechtseljirevapl g nekrelkaduukkepukneuzenl b lekuknimarc zwarting sneegotualnileppez o thcottiulekjirsobeauforteititondleebmaanjaar friteusergeribdagwerkaptaam nepmoppookroovoegwerkanklobruuvzoetstoffigaroeitamrofgninnapsmedignilraaneggojasucimehcasepot tr l myzneneusbeenwerkilr az l lnemmertsmoknaarbmempiriekenierediryoj kirptouwbaancienepacidnah raalerepuss c v njicupaknabnjip aorkstopseindig sgaadseztrehgimrovief p meikeverminkt oherlezensperwerpenantntnetteerzeep b t fv gbottinekuehcsigeleitnevegnidliubhcalslomzeggenielkus iinegrevoreih hoefstalfeorhcscolioseksshopgaannemercatorpedouanierebaanhefkeitsaleddimedjiznoz v t vjubeliegenopt rindirect yfdieenesaboksbaldadiggamajyplasmidejeuneruzaaddoosulytcad expressemralatnegenvigerenetsalebjibreihndn suspectw murtcelpitlumj grafw btukkerkerenipul loongolfmu muenireppiwto parcoursmtoortstiwkjiledrogillobuo i catalaanruoj ln j wraakosmsreizene z ohhongaars yshhoofdwassalonjuistg p nelewuaw f tnedivejtwueelitewmaarkurdleiw lebahcsimotaarefer glabgoogaadnavrantopping dnalednorgiegagen z p vraagalsknoh y driemankpootuohkah zvy otrekvisrijkenj getrouwd tragicus zwemen p koeltanku l reehmodeilosagthcillusierteov kajuitgiftejiressiveez r h t r beduidenatlantaarnereikzeikermis bondagekuifdsw b u e rn sf b nerutseb u p meitluccoetnemedaeb s h oi tnekahfa dtamtams parabeltoonreireokb bpcruisesimthcil u n p neioolviewdataarojam skamillegaalanimretnuocr g jn a f lneralkpokroobp a u r brunettelraam r n i d h o nwindvang gnitjiwk l i a eg laagheideviatie g kalkarm voorfilml wasspeld chutneygloeiend stattenmn u drobpotsulno panledebolvormleer reddelk nrsovouwlijn o vouwdeur osrsipsajremozab wid gnk pedelirium uw rednop mosb of nnasyntaxisloohcsinoi bareedsl t xoof n k zkeaivilc ptf i anereluoretehoekzak eevnielkkc z ioorn gk g vwtstayertg paplepel wiebelenj iaawzcirrusynaps w die zlokeend w c s j jirekkofsg zeemacht i p lhuiverig r u z e goudertsluho n indoorlerommel l tuuj d oiaabmoluoc hsacrobaat m t r o r h oacac w |
offtopic:
Ben ik trouwens de enige die figuren probeert te zoeken in de gemaakte grids? Ik weet, het is onzin, maar die grids zijn toch steeds weer "work of art" hoor.
Ben ik trouwens de enige die figuren probeert te zoeken in de gemaakte grids? Ik weet, het is onzin, maar die grids zijn toch steeds weer "work of art" hoor.
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
offtopic:
Dat grid in de post boven je lijkt op Afrika!
Dat grid in de post boven je lijkt op Afrika!
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
offtopic:
ik vind hem wel lijken op een marine uit starcraft
ik vind hem wel lijken op een marine uit starcraft
[ Voor 19% gewijzigd door 6K op 04-04-2007 08:57 ]
٩(͡๏̯͡๏)۶ ٩(●̮̮̃•̃)۶
Verwijderd
offtopic:
Hmm... Kun je met de vorm bonuspunten scoren?
Hmm... Kun je met de vorm bonuspunten scoren?
Meer on-topic: het gaat langzaam maar zeker de goede kant op met grid01.
code:
1
2
3
4
5
| Aantal woorden: 487 Aantal letters (bron): 3231 Aantal letters (grid): 1969 Percentage bespaard: 39.06 Percentage over: 60.94 |
Rekentijd: ongeveer 8 seconden. Vorm:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
| <grid01> n e n glycerol e s b s zwarting neffap n i bloeduok smedig dagwerkh t chromolslaacov z d j triadejeuneruzaaddoosinzagetrouwd wijnrekud njicupak f drkupekku minkukeluleeuwtje coloristramienif j t jw nerekrekkut zeevisserij o h k g etmiuretilevend l xdneieolg c tr snuffenegadnoboreez klneppetsruigtelfmap a uittochtlntjilvomzeggen reexpressergeribd m n cyprus rtnetteerzeepavva wollenloongolfntnagorgelen ejtleedjiznoz pe aiggam wbeauforteanyinterestarf verarmen rb s nekeobfares nlw t rauonikd z v l l mz feorhcs jwei eau u almbenrr p a netnakmosneograboksbaldadig bovenarmcashaastenau i h j uitroken h w laatraw biw l zttafhakenj bus p o stayertso r b sms handicapimpelenittob e v voorkoopgaannemercatorpedo neiurkposimthciloseksbomuseaalarm d galmbord d beo ld b madreek kaptafelitair rlichtgasoliedomheer o r ylokeend b e nt oculistopseindigii r l b sruocraphall lachbuildingeventieland klpke je oz i i b lammeren g nezuenkb kl vednipsar kg bu r nepmoppoib aewo femelaarms phypnoseemais i p o mlamsboutoogjilgnissaplacidea uhn umyznettatslnkaduuk u dactylusulhertz g toovedtuohkahbfid zeo ueneicnaabwuottoccultiem n s e eecs hangoor g r teitaivedertamtam hbasenipuloi dwindvangso wueinorabrzorgillobuomtelignippotamtdeitcesgaadsez i d iaii l g e zijwegvakreoretehmsipsajremozhztaarojam g i cramlg kalruuvi vv c kg s emneoziesperwerpenanteenr u lemmorelooizuurkastofgoudahji e gittteejtawieldrukraamwet e c p tcmeeeitamroffrusiois jvigerenetsalebjibreih ikd f i plasmideminderonerevelc koelweghonenakdigyentuhcei f c onjuistrikajuitgifteibvifehnaabereireok gerritnjilwuov jiredems krewletceridnionischoolsdeereffobroulerenier nesuspectk r krg multiplectrumt punt tknimrevekiemtavegatsulnor n mp tnemekakgoaokesnikken pyjamavlekkenroodnileppeze sejsiumoorvlooienwulgew krijtenataaliaakalkarm vond k s zriaelcunz u tnsup u l ak k aiaj gnigohpokroob t nklhptr i g h i rfi kmh s apopeninglabgoogae ywraak bosduif e lotenaneralkponderfvois l l b tostirotuas fokkerijsi e laatsteventgk douaniersvnediudeb superelaarihn wtoortsjekeld spranknatleoklal moes nekrelk e au d ilihcasepotua rr r n grdagoudertsb spitten nbaaitsmoknaarbmem w o ag i dtelraamsixatnys herladenn goacacip i pril reizenp u j oj tzhond r p ruedwuov ee c e vl oi n a vv d kazkeoh d r o w u o b |
Ziet er netjes uit hij, wat voor score haal je nu over de hele eerste testset (en de 2e en de 3e
)? En in welke tijd?
Zo, mijn programma poept nu ook een grid uit
Het is nog niet zo goed als de rest, maar nog wel retesnel... (Ik werk alleen wel in windows, en ik heb geen idee hoe ik em daar moet timen...)
Nu maar weer ff nadenken hoe het beter kan
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| grid01.txt: Aantal woorden: 487 Aantal letters voor: 3231 Aantal letters na: 2319 Percentage: 0.7177344475394615 grid02.txt: Aantal woorden: 578 Aantal letters voor: 3779 Aantal letters na: 2682 Percentage: 0.7097115639057952 grid03.txt: Aantal woorden: 560 Aantal letters voor: 3661 Aantal letters na: 2622 Percentage: 0.7161977601748156 grid04.txt: Aantal woorden: 429 Aantal letters voor: 2771 Aantal letters na: 1994 Percentage: 0.719595813785637 grid05.txt: Aantal woorden: 487 Aantal letters voor: 3178 Aantal letters na: 2291 Percentage: 0.7208936438011327 grid06.txt: Aantal woorden: 731 Aantal letters voor: 4768 Aantal letters na: 3386 Percentage: 0.7101510067114094 |
Nu maar weer ff nadenken hoe het beter kan

I see red pixels.
Gewoon in je code?wwwhizz schreef op zaterdag 07 april 2007 @ 17:57:
(Ik werk alleen wel in windows, en ik heb geen idee hoe ik em daar moet timen...)
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Tuurlijk!-NMe- schreef op zaterdag 07 april 2007 @ 18:05:
[...]
Gewoon in je code?Aan het begin de tijd opvragen, aan het eind nog een keer, en die twee waarden van elkaar aftrekken, klaar.

Ik heb het alleen nooit geleerd te gebruiken, is System.currentTimeMillis(); voldoende? (In Java)
Die geeft 8203ms aan..
edit: in een console duurt het 25ms korter
Deze tijd is overigens inclusief de uitvoer geven die ik net postte...
[ Voor 15% gewijzigd door RedPixel op 07-04-2007 18:25 ]
I see red pixels.
Tip: System.nanoTime() is een stuk nauwkeuriger en betrouwbaarder (currentTimeMillis() wil neemt namelijk stappen van 8 of 16 ms dacht ik).
Verwijderd
Nou, de scores waren niet echt daverend. Ik was bij het ontwikkelen uitgegaan van alleen grid01, dus de eerste woordenset van testset #1. Toen ik afgelopen woensdag voor het eerst de resterende subsets van set1 en de andere sets probeerde, vond ik het resultaat in vergelijking met grid01 maar magertjes, ik bleef (vooral bij de tweede en derde set) 25-50 chars per grid op je (Marcj dus) achter. Vandaag heb ik de AI getuned, en het ziet er nu aanzienlijk beter uit, gegeven de volgende resultaten.Marcj schreef op woensdag 04 april 2007 @ 12:49:
Ziet er netjes uit hij, wat voor score haal je nu over de hele eerste testset (en de 2e en de 3e)? En in welke tijd?
Woordset I:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
| BLOK 1: Aantal woorden: 487 Aantal letters (bron): 3231 Aantal letters (grid): 1945 Percentage bespaard: 39.8 Percentage over: 60.20 BLOK 2: Aantal woorden: 578 Aantal letters (bron): 3779 Aantal letters (grid): 2218 Percentage bespaard: 41.31 Percentage over: 58.69 BLOK 3: Aantal woorden: 560 Aantal letters (bron): 3661 Aantal letters (grid): 2161 Percentage bespaard: 40.97 Percentage over: 59.03 BLOK 4: Aantal woorden: 429 Aantal letters (bron): 2771 Aantal letters (grid): 1652 Percentage bespaard: 40.38 Percentage over: 59.62 BLOK 5: Aantal woorden: 487 Aantal letters (bron): 3178 Aantal letters (grid): 1905 Percentage bespaard: 40.06 Percentage over: 59.94 BLOK 6: Aantal woorden: 731 Aantal letters (bron): 4768 Aantal letters (grid): 2750 Percentage bespaard: 42.32 Percentage over: 57.68 |
Woordset II:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| BLOK 1: Aantal woorden: 487 Aantal letters (bron): 3132 Aantal letters (grid): 1840 Percentage bespaard: 41.25 Percentage over: 58.75 BLOK 2: Aantal woorden: 589 Aantal letters (bron): 3851 Aantal letters (grid): 2236 Percentage bespaard: 41.94 Percentage over: 58.06 BLOK 3: Aantal woorden: 902 Aantal letters (bron): 5864 Aantal letters (grid): 3278 Percentage bespaard: 44.1 Percentage over: 55.90 BLOK 4: Aantal woorden: 804 Aantal letters (bron): 5190 Aantal letters (grid): 2927 Percentage bespaard: 43.6 Percentage over: 56.40 BLOK 5: Aantal woorden: 571 Aantal letters (bron): 3740 Aantal letters (grid): 2198 Percentage bespaard: 41.23 Percentage over: 58.77 |
Woordset III:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| BLOK 1: Aantal woorden: 359 Aantal letters (bron): 3267 Aantal letters (grid): 2244 Percentage bespaard: 31.31 Percentage over: 68.69 BLOK 2: Aantal woorden: 378 Aantal letters (bron): 3512 Aantal letters (grid): 2415 Percentage bespaard: 31.24 Percentage over: 68.76 BLOK 3: Aantal woorden: 469 Aantal letters (bron): 4320 Aantal letters (grid): 2938 Percentage bespaard: 31.99 Percentage over: 68.01 BLOK 4: Aantal woorden: 366 Aantal letters (bron): 3399 Aantal letters (grid): 2379 Percentage bespaard: 30.01 Percentage over: 69.99 |
De benodigde rekentijden zijn ongeveer 4, 9.5 en 2 minuten voor de drie sets, maar dat zal in de definitieve versies aanzienlijk minder zijn vanwege de debug/assert code en nog lang niet optimale deelalgorithmen die er tijdens het ontwikkelen inzitten. Daarnaast zit er een stuk AI in voor suboptimalisaties, en die is eenvouding @36 seconden te stoppen.
Komende week ga ik nog wat nieuwe ideetjes uitproberen
Ok, thxMarcj schreef op zaterdag 07 april 2007 @ 18:42:
Tip: System.nanoTime() is een stuk nauwkeuriger en betrouwbaarder (currentTimeMillis() wil neemt namelijk stappen van 8 of 16 ms dacht ik).
[ Voor 16% gewijzigd door RedPixel op 08-04-2007 15:15 ]
I see red pixels.
nanoTime is helaas niet te gebruiken om multi-core/proc systemen. Dan krijg je de meest wazige resultaten (negatieve timestamps e.d.)Marcj schreef op zaterdag 07 april 2007 @ 18:42:
Tip: System.nanoTime() is een stuk nauwkeuriger en betrouwbaarder (currentTimeMillis() wil neemt namelijk stappen van 8 of 16 ms dacht ik).
De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"
Ow? Ik gebruik het hier al tijden en ik heb er nog nooit problemen mee gehad (op een Athlon X2 4200+).
Doet het hier ook prima op een X2 4800+NetForce1 schreef op dinsdag 10 april 2007 @ 08:58:
[...]
nanoTime is helaas niet te gebruiken om multi-core/proc systemen. Dan krijg je de meest wazige resultaten (negatieve timestamps e.d.)
I see red pixels.
Het hangt denk ik ook meer af van de VM implementatie. Vergelijkbare windows API functies hebben hier namelijk dezelfde problemen mee, en de kans is natuurlijk groot dat die functie met een dergelijke API geimplementeerd is.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Nu ik je post doorlees denk ik wat het probleem is. Jij denkt dat deze functie een timestamp teruggeeft, maar dat klopt niet helemaal. Er staat nergens gedefinieerd wat voor soort waarde je terug krijgt (je kunt er niet de huidige tijd aan uitlezen), maar het is bedoelt als timer. Dus lees twee verschillende waarden uit en bereken het verschil (tot 2^63 seconden ~ 292 jaar). Dit is het aantal nanoseconden wat dan verstreken is (misschien niet tot op de nanaseconde nauwkeurig, maar toch wel een stuk nauwkeuriger dan in microseconden).
Ik kan me wel voorstellen dat met een interne teller van één van de processoren gebruikt en als dit verkeerd geimplementeerd is dat de mogelijkheid bestaat dat eerst de ene processor wordt gebruik en daarna de andere. Maar ik heb het van Java SE 6 nog niet fout zien gaan.
Ik kan me wel voorstellen dat met een interne teller van één van de processoren gebruikt en als dit verkeerd geimplementeerd is dat de mogelijkheid bestaat dat eerst de ene processor wordt gebruik en daarna de andere. Maar ik heb het van Java SE 6 nog niet fout zien gaan.
Wij hebben het hier wel eens gebruikt met Java 5, en dat ging helemaal fout. Ik weet niet meer of het op WinXP was of op Ubuntu. Volgens mij was het verschil negatief tussen twee resultaten (wel de eerste van de tweede afgetrokken uiteraard). Met een search op Google kwamen we mensen tegen met hetzelfde probleem op multi-core processors, dus toen hebben we er verder niet naar gekeken.
De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"
Zo. Eigenlijk heb ik helemaal geen tijd hiervoor, maar het is erg verslavend!
Eerste zeer basic implementatie af, scores zijn dramatisch (rond de 70%) en snel is het ook niet echt (zo'n 30 seconden per grid). Wel minder dan 150 regels code, dus misschien dat dat nog iets oplevert?
Eerste zeer basic implementatie af, scores zijn dramatisch (rond de 70%) en snel is het ook niet echt (zo'n 30 seconden per grid). Wel minder dan 150 regels code, dus misschien dat dat nog iets oplevert?
Is er ook een prijs voor de meeste compressie per seconde?
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| grid01.txt: Woorden: 487 Letters voor en na: 3231->2357 Percentage 72.95 grid02.txt: Woorden: 578 Letters voor en na: 3779->2694 Percentage 71.289 grid03.txt: Woorden: 560 Letters voor en na: 3661->2613 Percentage 71.374 grid04.txt: Woorden: 429 Letters voor en na: 2771->1979 Percentage 71.418 grid05.txt: Woorden: 487 Letters voor en na: 3178->2301 Percentage 72.404 grid06.txt: Woorden: 731 Letters voor en na: 4768->3365 Percentage 70.575 Klaar in: 1.4273 seconden |
[ Voor 5% gewijzigd door RedPixel op 10-04-2007 21:56 . Reden: -> naar lowercase moet natuurlijk ook nog ]
I see red pixels.
Verwijderd
Ha wwwhizz, klasse, jij gaat duidelijk voor de snelste oplossing, die tijd van jou haal ik echt niet met m'n huidige proggie
.
Ik ga zelf voor zo goed mogelijke oplossingen, en zal daarbij proberen de beschikbare tijd zo volledig mogelijk te benutten. Aangezien je gemiddeld per grid 36 seconden hebt, mag ik dus 216 seconden besteden aan testset I. Als ik m'n huidige test-programma op een geschikt moment laat stoppen, komt 'ie na 205 seconden met de volgende resultaten:
Dus langzaam maar zeker knabbel ik er nog wat vanaf. Maar het wordt wel steeds moeilijker om nog enige vooruitgang te boeken.
En MarkJ, wanneer kunnen we weer wat spektakel van jou verwachten
?
Ik ga zelf voor zo goed mogelijke oplossingen, en zal daarbij proberen de beschikbare tijd zo volledig mogelijk te benutten. Aangezien je gemiddeld per grid 36 seconden hebt, mag ik dus 216 seconden besteden aan testset I. Als ik m'n huidige test-programma op een geschikt moment laat stoppen, komt 'ie na 205 seconden met de volgende resultaten:
code:
1
2
3
4
5
6
| grid01: 1939 grid02: 2204 grid03: 2155 grid04: 1659 grid05: 1887 grid06: 2728 |
Dus langzaam maar zeker knabbel ik er nog wat vanaf. Maar het wordt wel steeds moeilijker om nog enige vooruitgang te boeken.
En MarkJ, wanneer kunnen we weer wat spektakel van jou verwachten
Verwijderd
TimeStampCounter en AMD dual-core issueNetForce1 schreef op dinsdag 10 april 2007 @ 13:20:
Wij hebben het hier wel eens gebruikt met Java 5, en dat ging helemaal fout. Ik weet niet meer of het op WinXP was of op Ubuntu. Volgens mij was het verschil negatief tussen twee resultaten (wel de eerste van de tweede afgetrokken uiteraard). Met een search op Google kwamen we mensen tegen met hetzelfde probleem op multi-core processors, dus toen hebben we er verder niet naar gekeken.
Wat mijn eigen ervaringen betreft: ik gebruik voor micro-seconden timing onder Windows (NT4 & W2K) al een decennium de in die link genoemde Win32 API calls QueryPerformanceFrequency() en QueryPerformanceCounter(), en die hebben voor zover ik me weet te herinneren, zowel op bijvoorbeeld single-core PIII-s als op een 4400+ X2 (al anderhalf jaar) altijd vlekkeloos gewerkt. Ik roep ze trouwens rechtstreeks aan vanuit C++ code ontwikkeld met Visual C++.
Nope, driver en BIOS bugs hebben ervoor gezorgd dat QPC niet altijd goed heeft gewerkt. MS raadt ook zelf aan om QPC slechts vanuit 1 thread aan te roepen met een affinity mask op 1 CPU.
[q=http://msdn2.microsoft.com/en-us/library/bb173458.aspx]
[q=http://msdn2.microsoft.com/en-us/library/bb173458.aspx]
- Compute all timing on a single thread. Computation of timing on multiple threads — for example, with each thread associated with a specific processor — greatly reduces performance of multi-core systems.
- Set that single thread to remain on a single processor by using the Windows API SetThreadAffinityMask. Typically, this is the main game thread. While QueryPerformanceCounter and QueryPerformanceFrequency typically adjust for multiple processors, bugs in the BIOS or drivers may result in these routines returning different values as the thread moves from one processor to another. So, it's best to keep the thread on a single processor.
All other threads should operate without gathering their own timer data. We do not recommend using a worker thread to compute timing, as this will become a synchronization bottleneck. Instead, worker threads should read timestamps from the main thread, and because the worker threads only read timestamps, there is no need to use critical sections.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Hmm goeie resultatenVerwijderd schreef op woensdag 11 april 2007 @ 00:11:
Ha wwwhizz, klasse, jij gaat duidelijk voor de snelste oplossing, die tijd van jou haal ik echt niet met m'n huidige proggie.
Ik ga zelf voor zo goed mogelijke oplossingen, en zal daarbij proberen de beschikbare tijd zo volledig mogelijk te benutten. Aangezien je gemiddeld per grid 36 seconden hebt, mag ik dus 216 seconden besteden aan testset I. Als ik m'n huidige test-programma op een geschikt moment laat stoppen, komt 'ie na 205 seconden met de volgende resultaten:
code:
1 2 3 4 5 6 grid01: 1939 grid02: 2204 grid03: 2155 grid04: 1659 grid05: 1887 grid06: 2728
Dus langzaam maar zeker knabbel ik er nog wat vanaf. Maar het wordt wel steeds moeilijker om nog enige vooruitgang te boeken.
En MarkcJ, wanneer kunnen we weer wat spektakel van jou verwachten?
Hoe kom je aan die 36 seconden?Verwijderd schreef op woensdag 11 april 2007 @ 00:11:
Ha wwwhizz, klasse, jij gaat duidelijk voor de snelste oplossing, die tijd van jou haal ik echt niet met m'n huidige proggie.
Ik ga zelf voor zo goed mogelijke oplossingen, en zal daarbij proberen de beschikbare tijd zo volledig mogelijk te benutten. Aangezien je gemiddeld per grid 36 seconden hebt, mag ik dus 216 seconden besteden aan testset I.
Ik heb trouwens nog wat zitten verbeteren (niet qua snelheid..)
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| grid01.txt: Woorden: 487 Letters voor en na: 3231->2212 Percentage 68.462 grid02.txt: Woorden: 578 Letters voor en na: 3779->2534 Percentage 67.055 grid03.txt: Woorden: 560 Letters voor en na: 3661->2478 Percentage 67.686 grid04.txt: Woorden: 429 Letters voor en na: 2771->1872 Percentage 67.557 grid05.txt: Woorden: 487 Letters voor en na: 3178->2157 Percentage 67.873 grid06.txt: Woorden: 731 Letters voor en na: 4768->3209 Percentage 67.303 Klaar in: 1.9364 seconden |
[ Voor 0% gewijzigd door RedPixel op 11-04-2007 17:10 . Reden: Toch nog een kleine snelheidsverbetering gevonden :*) ]
I see red pixels.
De meest uitzonderlijke situatie:
Je hebt 99 grids die in een uur uitgerekend moeten zijn.
Dan is je gemiddelde tijd per grid dus maximaal (60 minuten = 3600 seconden) / 99 grids = 36 seconden.
Edit @ edit: Noem dat maar klein, dat was 20% sneller
Je hebt 99 grids die in een uur uitgerekend moeten zijn.
Dan is je gemiddelde tijd per grid dus maximaal (60 minuten = 3600 seconden) / 99 grids = 36 seconden.
Edit @ edit: Noem dat maar klein, dat was 20% sneller
[ Voor 12% gewijzigd door KoW op 11-04-2007 17:13 ]
3600 seconden (1 uur) / 99 woordgroepen ~= 36 seconden.wwwhizz schreef op woensdag 11 april 2007 @ 17:04:
Hoe kom je aan die 36 seconden?
Maar dit is heel erg nattevingerwerk natuurlijk. Het is waar dat je bij een maximaal aantal sets aan woorden gemiddeld 36 seconden over een grid mag doen maar er spelen afhankelijk van je algoritme veel meer factoren mee. Als de woorden langer zijn dan in de aangeleverde testsets of de sets bestaan uit meer woorden dan in de testsets dan is 36 seconden een veel te ruime grens om op te gaan zitten en is het veiliger om zo'n 10 seconden per grid te proberen te halen met de huidige testsets.
Het mooiste is een algoritme dat schaalbaar is naar tijd. Op die manier kun je afhankelijk van de hoeveelheid aangeleverde woorden proberen de beschikbare tijd naar het maximum uit te vullen. Maar of de organisatie er heel blij van wordt dat elke inzending precies een uur staat te stampen...
Ik ben net begonnen om een implementatie te maken in C# omdat dat iets sneller implementeert dan C/C++ (tijdsgebrek hè). Maar wat onherroepelijk gaat knagen is dat er een stuk minder aan de datastructuren te optimaliseren valt dan in C. Nou ja, een goed algoritme is doorgaans beter dan welke codeoptimalisatie dan ook, dus we houden de moed er in.
Edit: sneller of minder typen.
Ik snap niet hoe jullie zulke goede scores kunnen halen
Ik dacht dat ik toch al een heel goed algoritme heb, maar als ik mijn programma 10 minuten laat rekenen over grid 1 uit testset 1 dan krijg ik dit resultaat:
grid01.txt:
Woorden: 487
Letters voor en na: 3231->2209
Percentage 68.369
(slechts 1 promille verbetering ten opzichte van mijn 0,4 seconden check...)
grid01.txt:
Woorden: 487
Letters voor en na: 3231->2209
Percentage 68.369
(slechts 1 promille verbetering ten opzichte van mijn 0,4 seconden check...)
I see red pixels.
Arty_Shock schreef op woensdag 11 april 2007 @ 17:23:
... Nou ja, een goed algoritme is doorgaans beter dan welke codeoptimalisatie dan ook...
Da's waar, maar bij mij scheelde het toch enom, die code optimalisatie. Nu was dat voornamelijk het gebruik van een andere functie binnen de taal die precies hetzelfde veel sneller deed.
De overige optimalisaties bestonden voornamelijk uit implementatie verbeteringen.
* KoW begrijpt nog niet helemaal welk algoritme jij (en sommige anderen) gebruikt dat je een doorlooptijd hebt die zo kan varieren voor hetzelfde algoritme.wwwhizz schreef op vrijdag 13 april 2007 @ 17:43:
Ik snap niet hoe jullie zulke goede scores kunnen halenIk dacht dat ik toch al een heel goed algoritme heb, maar als ik mijn programma 10 minuten laat rekenen over grid 1 uit testset 1 dan krijg ik dit resultaat:
Eigenlijk heb ik nog te veel werk in te halen, maar toch wil ik vandaag weer een nieuw opzetje maken.
Met het vorige concept viel verder niet veel eer meer te behalen.
Het was redelijk snel, maar er waren al teveel anderen die in een kortere tijd een lagere score neerzetten.
Het algoritme was nog wel wat te optimaliseren voor een iets lagere score, maar dat zou weer meer tijd kosten.
Dus: tijd voor een nieuw algoritme.
Dat gaat wel een stuk trager zijn, maar het zou wel een score verbetering moeten geven.
Na wat kleine bugjes is het toch gelukt.
Het algoritme is zoals verwacht erg traag en levert bovendien ook nog niet echt goede scores op.
Nu nog zien dat de snelheid vertienvoudigd en dat er 10% van de score af gaat
code:
1
2
3
4
5
6
7
8
9
| BLOK 1 Compleet Aantal woorden: 487 Aantal letters (bron): 3231 Aantal letters (grid): 2050 Percentage bespaard: 36.55 Percentage over: 63.45 |
Edit:
De snelheid wil nog niet echt lukken.
De nieuwste versie doet een minuut over een score van 63.70 %
[ Voor 17% gewijzigd door KoW op 17-04-2007 20:54 ]
Ik denk dat ik wel zowat klaar ben, hoe kan ik een Java programma het beste aanleveren?
I see red pixels.
Per email.wwwhizz schreef op woensdag 18 april 2007 @ 17:28:
Ik denk dat ik wel zowat klaar ben, hoe kan ik een Java programma het beste aanleveren?
Ontopic: gewoon een command file voor unix/windows en de .jar file zou toch moeten volstaan? Ik neem aan dat de organisatoren netjes een java VM hebben geïnstalleerd, anders krijg ik met m'n .Net 2.0 framework als vereiste ook nog problemen.
Er lijken verder geen regels wat betreft de "executable" te zijn, behalve dat 'ie met één simpel commando op te starten moet zijn en vervolgens z'n werk moet doen, zonder poespas.
Maar ehm... Ik ben voor anderen aan het spreken dus let vooral niet op mij.
[ Voor 31% gewijzigd door ArtyShock op 18-04-2007 23:43 ]
Java spul kan ingeleverd worden als executable, liefst met de source in de jarfile, maar alles los mag ook.
Zolang je maar een executable en de source inlevert en eventuele instructies voor de uitvoering erbij doet is alles prima.
Nou ik toch aan het posten ben: ik wil iedereen er nog even extra op wijzen dat duidelijk commentaar je score kan beïnvloeden. Als wij de bedoeling achter een vreemd ogend stukje code snappen, dan reageren we daar misschien wel anders op in de beoordeling.
Nou ik toch aan het posten ben: ik wil iedereen er nog even extra op wijzen dat duidelijk commentaar je score kan beïnvloeden. Als wij de bedoeling achter een vreemd ogend stukje code snappen, dan reageren we daar misschien wel anders op in de beoordeling.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
En anders doen persoonlijke complimentjes, omkopingen en andere 'goedbedoelde' teksten in je source het ook altijd goed
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Verwijderd
Valt hieronder ook (vast wel goed bedoeld) commentaar zoals het volgende, dat ik ooit aantrof in een stuk code afkomstig van het CMU?RobIII schreef op donderdag 19 april 2007 @ 10:40:
... 'goedbedoelde' teksten in je source het ook altijd goed
C:
1
2
3
4
5
6
| /* WARNING: Ultra-hot columnization package. If you think you understand * this code, you don't. What was once a confused idea of David * Garlan and Ravinder Chandhok, has now been tained beyond belief * by the hands of Joan Disk and the Gnomehearts. * (Draw skull and bones here.) */ |
Verwijderd
Wat wordt het, Grolsch of Hertog Jan?RobIII schreef op donderdag 19 april 2007 @ 10:40:
En anders doen persoonlijke complimentjes, omkopingen en andere 'goedbedoelde' teksten in je source het ook altijd goed
Ik heb gewoon de .class bestanden + een readme + de source in een .rar gezet en dat opgestuurd, dat is genoeg hopelijk? Ik heb geprobeerd er een .jar van te maken maar dat gaf foutmeldingen en ik had geen zin om het uit te zoeken-NMe- schreef op donderdag 19 april 2007 @ 09:36:
Java spul kan ingeleverd worden als executable, liefst met de source in de jarfile, maar alles los mag ook.Zolang je maar een executable en de source inlevert en eventuele instructies voor de uitvoering erbij doet is alles prima.
Nou ik toch aan het posten ben: ik wil iedereen er nog even extra op wijzen dat duidelijk commentaar je score kan beïnvloeden. Als wij de bedoeling achter een vreemd ogend stukje code snappen, dan reageren we daar misschien wel anders op in de beoordeling.
I see red pixels.
Je hebt anderswwwhizz schreef op donderdag 19 april 2007 @ 18:52:
Ik heb geprobeerd er een .jar van te maken maar dat gaf foutmeldingen en ik had geen zin om het uit te zoeken
[ Voor 13% gewijzigd door RobIII op 19-04-2007 19:24 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Ik heb het nu al ingestuurd
[edit @edit] Jah, dat had ik ook wel door

[ Voor 158% gewijzigd door RedPixel op 19-04-2007 20:03 ]
I see red pixels.
offtopic:
* KoW mocht dat ooit wel.
* KoW mocht dat ooit wel.
Vraagje, is het een probleem wanneer de executable andere executables aanroept ?
* KoW heeft nog nooit met multithreading gewerkt.
Ik weet niet welke IDE gebruikt, maar iig kan je met eclipse heel makkelijk een project exporteren als jar-bestand. Gewoon via File -> Export -> Jar Filewwwhizz schreef op donderdag 19 april 2007 @ 18:52:
[...]
Ik heb gewoon de .class bestanden + een readme + de source in een .rar gezet en dat opgestuurd, dat is genoeg hopelijk? Ik heb geprobeerd er een .jar van te maken maar dat gaf foutmeldingen en ik had geen zin om het uit te zoeken
Als ik dan dubbelklik op de .jar zegt ie "failed to load main-class manifest attribute from *bestandsnaam*"Marcj schreef op donderdag 19 april 2007 @ 20:32:
[...]
Ik weet niet welke IDE gebruikt, maar iig kan je met eclipse heel makkelijk een project exporteren als jar-bestand. Gewoon via File -> Export -> Jar File
I see red pixels.
Je kan toch instellen welke class de main-class is? Volgens mij komt die optie in de exporteer functie wel voor.
How much can you compute with the "ultimate laptop" with 1 kg of mass and 1 liter of volume? Answer: not more than 10^51 operations per second on not more than 10^32 bits.
In de derde stap van de wizard moet je wel een Main class opgeven (onderaan), en aangeven dat je een manifest file wilt genereren (bovenste radio button).wwwhizz schreef op donderdag 19 april 2007 @ 20:38:
[...]
Als ik dan dubbelklik op de .jar zegt ie "failed to load main-class manifest attribute from *bestandsnaam*"
Pff, waarom kijk ik daar overheen?
Bedankt in ieder geval, weet ik dat voor de volgende keer

I see red pixels.
Och, het is geen ramp. Zolang we met één commando de boel kunnen runnen én de source erbij zit hoor je ons niet klagen. 
Op zich is dat prima, als eventuele executables waar je afhankelijk van bent ook maar bijgevoegd worden, inclusief sources. Alleen: wat heeft dat met multithreading te maken?KoW schreef op donderdag 19 april 2007 @ 20:19:
Vraagje, is het een probleem wanneer de executable andere executables aanroept ?
* KoW heeft nog nooit met multithreading gewerkt.
[ Voor 29% gewijzigd door NMe op 20-04-2007 09:30 ]
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
* KoW wou het gebruiken als alternatief voor multithreading. (meer multiprocessor)
Gewoon een basis exe 2 of 4 andere exe's laten starten die dan elk een deel van het werk doen.
Gewoon een basis exe 2 of 4 andere exe's laten starten die dan elk een deel van het werk doen.
Zo moeilijk hoeft multi-threading ook alweer niet te zijn, plus dat dit natuurlijk een mooie kans is om iets nieuws te leren
Als je verder geen multithreading programmeert in je hoofdprogramma, dan is er van multithreading ook geen sprake als je andere exe's gaat aanroepen. De zaak wordt dan gewoon lineair uitgevoerd. En zelfs als het wel zo zou werken, dan is het veel makkelijker om processen met elkaar te laten communiceren als deze in dezelfde file verwerkt zitten.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.