mboost-dp1
unknown
Som tidligere deltager kan jeg oplyse, at det er en fantastisk oplevelse at deltage i sådan en olympiade. Så hvis man tror på, man har den mindste chance for at kvalificere sig, så bør man gøre forsøget. (Bemærk, det er en fordel at hedde Kasper :-)
Hvad er årsagen til at man kun må bruge de 3 sprog, og ikke de mere moderne sprog som C#, Java osv ?
Hvorfor er det kun skole knægte der må være med :s
Nå men held og lykke til de der måtte tage turen ! :)
Nå men held og lykke til de der måtte tage turen ! :)
#7
De skal kunne køre inden for en bestemt tids, og hukommelsesgrænse. Oftest et sekund og 16MB. Derfor er det direkte dumt at bruge sprog der kræver et specielt RE. Derfor må man ikke bruge højniveau sprog, såsom Java og C#.
Tilmeld jer, så I får opgaverne. Så kan I altid se om I får tid til at løse dem i løbet af ugen.
De skal kunne køre inden for en bestemt tids, og hukommelsesgrænse. Oftest et sekund og 16MB. Derfor er det direkte dumt at bruge sprog der kræver et specielt RE. Derfor må man ikke bruge højniveau sprog, såsom Java og C#.
Tilmeld jer, så I får opgaverne. Så kan I altid se om I får tid til at løse dem i løbet af ugen.
#6: Kan jeg skrive under på (også tidligere deltager)
#7: Tror det er noget med at få det til at køre med deres valideringssystem. Men tror nok der har været snak om at tillade Java i et par år, men så er der problemer med at Java kører langsommere end C++ programmer, og de derfor måske skal have mere tid osv. Noget lignende er nok gældende for C#
#8: Der er jo også ACM hvis du er på et universitet, eller Google CodeJam og den anden der som jeg ikke kan huske, som er uden deltagerkrav (mere eller mindre).
#7: Tror det er noget med at få det til at køre med deres valideringssystem. Men tror nok der har været snak om at tillade Java i et par år, men så er der problemer med at Java kører langsommere end C++ programmer, og de derfor måske skal have mere tid osv. Noget lignende er nok gældende for C#
#8: Der er jo også ACM hvis du er på et universitet, eller Google CodeJam og den anden der som jeg ikke kan huske, som er uden deltagerkrav (mere eller mindre).
#7:
Dengang jeg var med talte de om at indføre Java.
Men da Java er inteprereret ville programmerne ikke kunne sammenlignes med programmerne i C/C++ og Pascal.
Der måles på ren ydelse. Kravet var typisk at det skulle kunne køre færdigt og retunere nul i 1 eller 2 sekunder på en 200 MHz Linux maskine med 32 MB ram (dette blev emuleret). I de værste tests brugte programmerne typisk 95% af den tilladte tid.
Selvom man ikke længere bemærker at Java er intepreret i dagligt brug. Så skulle de tests nok opdage det, hvis Java programmer blev bedømt på samme kriterier som C/C++ og Pascal
EDIT: Som #10 allerede har skrevet
Dengang jeg var med talte de om at indføre Java.
Men da Java er inteprereret ville programmerne ikke kunne sammenlignes med programmerne i C/C++ og Pascal.
Der måles på ren ydelse. Kravet var typisk at det skulle kunne køre færdigt og retunere nul i 1 eller 2 sekunder på en 200 MHz Linux maskine med 32 MB ram (dette blev emuleret). I de værste tests brugte programmerne typisk 95% af den tilladte tid.
Selvom man ikke længere bemærker at Java er intepreret i dagligt brug. Så skulle de tests nok opdage det, hvis Java programmer blev bedømt på samme kriterier som C/C++ og Pascal
EDIT: Som #10 allerede har skrevet
[url=#7]#7[/url] Disky
[url=#8]#8[/url] webwarp
[url=#9]#9[/url] jK78Fxhjlfgvpc
Jeg kan huske engang vi dagen før konkurrencen diskuterede hvordan man i sit program kunne holde øje med tiden og afslutte lige før tiden udløb. Det kunne være praktisk hvis man havde fundet en løsning, men ikke var sikker på om det var den bedste. Så kunne programmet lede videre indtil tidsgrænsen blev nået og i sidste øjeblik aflevere et resultat.
Jeg gjorde selv brug af det i en enkelt opgave, men desværre ikke noget jeg fik gavn af, for mit program havde slet ingen løsning og spyttede bare et tilfældigt (og naturligvis forkert) svar ud.
Der var et kammerahold, der spurgte om de måtte have lov at komme ind og filme evalueringen. Det fik de lov til, for jeg vidste jo godt, at hverken kammerahold eller min egen nervøsitet kunne påvirke udfaldet. Men det var faktisk sjovt at side og fornemme hvordan de nærmest stod bagved og bed negle da tiden nærmede sig 20sek grænsen og så åndede lettet op hver gang mit program meldte tilbage efter 19.5sek. Ud af 10 tests gav mit program hurtigt korrekt svar på de 5 første tests, og et forkert svar i sidste øjeblik på de sidste 5 tests.
Men dengang kørte man jo DOS, og hvis programmet gik i en løkke skulle maskinen genstartes, så evalueringen gik da lidt hurtigere pga. mit check på tiden.
#10[/url] Shiyee
[url=#11]#11[/url] sago007
Jeg kan dog huske et enkelt tilfælde, hvor man skulle arbejde på så store datamængder, at det tog 60% af den tilladte tid bare at læse data ind fra disk. Og hvis ikke man var omhyggelig med at bruge buffering røg man hurtigt op på 90% af tiden brugt på disklæsning.
[url=#13]#13[/url] Disky
Nu kommer jeg til at tænke på dengang jeg brugte to timer på en smart algoritme som jeg til sidst måtte kassere fordi den ikke kunne køre inden for de 64KB stak man havde i real mode. Dernæst brugte jeg en time på en ikke helt så smart algoritme, som så alligevel endte med at score 99% af de mulige point. De to timer jeg spildte der kunne med fordel være udnyttet på en af de andre to opgaver, der skulle løses den dag.
Hvad er årsagen til at man kun må bruge de 3 sprog, og ikke de mere moderne sprog som C#, Java osv ?Det kan jo være et levn fra tidligere. Dengang IOI startede var der jo ikke noget, der hed Java.
[url=#8]#8[/url] webwarp
Hvorfor er det kun skole knægte der må være medACM har en lignende konkurrence for universitetsstuderende. ACM er lidt anderledes, der er nemlig tale om en holdkonkurrence. Et hold består af tre personer, men får kun stillet én computer til rådighed. Man skal altså sætte sig ned med et stykke papir og gennemtænke sin løsning så man er sikker på den virker, når den bliver tastet ind. En anden forskel er, at i ACM konkurrencen bliver besvarelserne evalueret øjeblikkeligt mens konkurrencen står på. I ACM er det kun fuldstændigt korrekte besvarelser der tæller, men bliver en besvarelse afvist kan man prøve igen. Når to hold løser lige mange opgaver afgøres vinderen udfra hvor mange forsøg og hvor lang tid man har brugt på dem. Hver gang man får godkendt en opgave får man en ballon, forskellige farver til hver opgave, så man kan følge med i hvor langt de andre hold er nået. Det gør konkurrencen ret intens.
[url=#9]#9[/url] jK78Fxhjlfgvpc
De skal kunne køre inden for en bestemt tids, og hukommelsesgrænse. Oftest et sekund og 16MB.Computerne har godtnok udviklet sig siden dengang jeg deltog :-) Vi havde 20 sekunder til de fleste opgaver, og kun 4MB RAM i computeren (men Turbo Pascal havde jo en 640KB begrænsning).
Jeg kan huske engang vi dagen før konkurrencen diskuterede hvordan man i sit program kunne holde øje med tiden og afslutte lige før tiden udløb. Det kunne være praktisk hvis man havde fundet en løsning, men ikke var sikker på om det var den bedste. Så kunne programmet lede videre indtil tidsgrænsen blev nået og i sidste øjeblik aflevere et resultat.
Jeg gjorde selv brug af det i en enkelt opgave, men desværre ikke noget jeg fik gavn af, for mit program havde slet ingen løsning og spyttede bare et tilfældigt (og naturligvis forkert) svar ud.
Der var et kammerahold, der spurgte om de måtte have lov at komme ind og filme evalueringen. Det fik de lov til, for jeg vidste jo godt, at hverken kammerahold eller min egen nervøsitet kunne påvirke udfaldet. Men det var faktisk sjovt at side og fornemme hvordan de nærmest stod bagved og bed negle da tiden nærmede sig 20sek grænsen og så åndede lettet op hver gang mit program meldte tilbage efter 19.5sek. Ud af 10 tests gav mit program hurtigt korrekt svar på de 5 første tests, og et forkert svar i sidste øjeblik på de sidste 5 tests.
Men dengang kørte man jo DOS, og hvis programmet gik i en løkke skulle maskinen genstartes, så evalueringen gik da lidt hurtigere pga. mit check på tiden.
#10[/url] Shiyee
men så er der problemer med at Java kører langsommere end C++ programmer, og de derfor måske skal have mere tid osv.Dengang jeg deltog kunne man også skrive i Basic, og jeg synes at erindre, at Basic programmerne fik lov til at bruge lidt mere tid. Men så afgørende er det nu heller ikke, for om man bruger en god eller en dårlig algoritme gør en langt større forskel end hvor effektivt sproget bliver afviklet. Der kan altså sagtens være tilfælde hvor en god løsning i Java/Basic tager et enkelt sekund mens en dårlig løsning i C ville tage flere timer.
[url=#11]#11[/url] sago007
I de værste tests brugte programmerne typisk 95% af den tilladte tid.Så har det nok været en dårlig algoritme man har brugt. For jeg mener at opgaverne plejer at kunne løses på ganske få procent af den tilladte tid, hvis man ellers finder en smart algoritme. Men som jeg selv nævner, så kan man jo bevidst sigte efter at udnytte tiden 95% ud, hvis der er håb om at finde en bedre løsning.
Jeg kan dog huske et enkelt tilfælde, hvor man skulle arbejde på så store datamængder, at det tog 60% af den tilladte tid bare at læse data ind fra disk. Og hvis ikke man var omhyggelig med at bruge buffering røg man hurtigt op på 90% af tiden brugt på disklæsning.
[url=#13]#13[/url] Disky
Hvis det er ren performance, hvorfor må man så ikke bruge assembler ?Fordi en optimerende compiler gør det ret godt, og kan udnytte små performance detaljer i hardwaren så godt, at den til tider kan slå en assemblerprogrammør. Og desuden fordi algoritmen er vigtigere end sprogets performance. Og det er sværere at kode assembler, så den tid man spilder på at debugge assemblerkode var bedre brugt på at udtænke en bedre algoritme eller måske rette lidt flere fejl i koden eller kunne bruges på en anden opgave.
Nu kommer jeg til at tænke på dengang jeg brugte to timer på en smart algoritme som jeg til sidst måtte kassere fordi den ikke kunne køre inden for de 64KB stak man havde i real mode. Dernæst brugte jeg en time på en ikke helt så smart algoritme, som så alligevel endte med at score 99% af de mulige point. De to timer jeg spildte der kunne med fordel være udnyttet på en af de andre to opgaver, der skulle løses den dag.
kasperd:
Hvis algoritmen er vigtigere end performance, så holder forklaringen med Java/C# jo ikke. :-)
Du siger dine 2 timer kunne være brugt bedre, men det er jo ikke sikkert du havde gjort det ligeså godt hvis du ikke havde brugt den tid.
Ja compilerne i dag kan oftest gøre arbejdet godt nok, men til visse ting slipper du ikke uden om håndoptimering af koden, f.eks. meget små embeddede systemmer, DSP'ere osv. :-)
Jeg vil ihvertefalde ikke mene de år jeg har kodet assembler på C64 og Amigaen har været spildt tværtimod, har jeg en langt større forståelse for optimering osv, end f.eks. en datamatiker har idag, eller datalog for den sags skyld :-) (i dag er jeg dataingeniør).
Hvis algoritmen er vigtigere end performance, så holder forklaringen med Java/C# jo ikke. :-)
Du siger dine 2 timer kunne være brugt bedre, men det er jo ikke sikkert du havde gjort det ligeså godt hvis du ikke havde brugt den tid.
Ja compilerne i dag kan oftest gøre arbejdet godt nok, men til visse ting slipper du ikke uden om håndoptimering af koden, f.eks. meget små embeddede systemmer, DSP'ere osv. :-)
Jeg vil ihvertefalde ikke mene de år jeg har kodet assembler på C64 og Amigaen har været spildt tværtimod, har jeg en langt større forståelse for optimering osv, end f.eks. en datamatiker har idag, eller datalog for den sags skyld :-) (i dag er jeg dataingeniør).
[url=#15]#15[/url] Disky
[url=#16]#16[/url] elscorpio
Hvis algoritmen er vigtigere end performance, så holder forklaringen med Java/C# jo ikke.Det var heller ikke mig, der brugte performance som begrundelse for, at Java/C# ikke skulle være tilladt.
Du siger dine 2 timer kunne være brugt bedre, men det er jo ikke sikkert du havde gjort det ligeså godt hvis du ikke havde brugt den tid.Det siger jeg, fordi den algortime jeg endte med at implementere havde jeg udtænkt meget tidligt. Men jeg havde forkastet den simple algoritme fordi jeg vurderede, at den ikke var god nok. Dernæst brugte jeg to timer i et forsøg på at implementere noget smartere, og endte så med at implementere den simple alligevel. Den simple algoritme gav så vidt jeg husker et sted mellem 95 og 99 procent af de mulige point.
Jeg vil ihvertefalde ikke mene de år jeg har kodet assembler på C64 og Amigaen har været spildt tværtimod, har jeg en langt større forståelse for optimering osvEnig. At kode assembler giver en meget god forståelse for hvordan maskinen virker. Det er et udmærket værktøj til at lære noget, men det er mindre anvendeligt til at implementere et større stykke software.
[url=#16]#16[/url] elscorpio
På en skole har underviser de stadig i assembler, dog ikke så dybdegående de kun er del af faget. Maskinarkitektur på Niels brock.Jeg har faktisk selv instrueret i maskinarkitektur på universitetet. Det er stadigvæk en obligatorisk del af datalogiuddannelsen. (Og der er 100 studerende, som kan bekræfte, at jeg har styr på det).
[url=#18]#18[/url] smurf
Ud af de fire finalister fra 97 var vi to, der starede på Daimi med det samme. Derudover var der tre af de andre deltagere fra DDD, som også startede på Daimi. Det vil sige, at ud af de 10 DDD deltager, jeg lige kan komme i tanke om, er syv startet på Daimi.
Hvor mange af finalisterne ryger efterfølgende ind på datalogi på AU?Ud af de fire finalister fra 96 var der to som starede på Daimi med det samme og jeg selv starede året efter. Og efter mit forsvar engang i løbet af vinteren vil vi alle tre have opnået en PhD.
Ud af de fire finalister fra 97 var vi to, der starede på Daimi med det samme. Derudover var der tre af de andre deltagere fra DDD, som også startede på Daimi. Det vil sige, at ud af de 10 DDD deltager, jeg lige kan komme i tanke om, er syv startet på Daimi.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund