mboost-dp1
Flickr - HJ Barraza
Desværre er det bare ikke programmeringsopgaver, men matemtik opgaver, der løses med programmering som regnemaskine. Se fx opgaverne fra sidste år:
http://ncpc.idi.ntnu.no/ncpc2009/ncpc2009problems....
Hvorfor dækker problemerne ikke emner som "minimering af resourceforbrug", "kodens læsbarhed", "low level programming", "high level programmering", etc?
http://ncpc.idi.ntnu.no/ncpc2009/ncpc2009problems....
Hvorfor dækker problemerne ikke emner som "minimering af resourceforbrug", "kodens læsbarhed", "low level programming", "high level programmering", etc?
Tilføjelse til #2
Du må kun medtage håndskrevne eller printede dokumenter, ikke noget med at have en masse på digital form.
Du bliver henvist til en PC klargjort af arrangørerne som indeholder forvalgt IDE/programmeringssprog som er enten C, C++ eller Java.
Sidst men ikke mindst, den eneste netværkstraffik du må generere skal ske i forbindelse med indsending af din løsning.
Du må kun medtage håndskrevne eller printede dokumenter, ikke noget med at have en masse på digital form.
Du bliver henvist til en PC klargjort af arrangørerne som indeholder forvalgt IDE/programmeringssprog som er enten C, C++ eller Java.
Sidst men ikke mindst, den eneste netværkstraffik du må generere skal ske i forbindelse med indsending af din løsning.
hunn (3) skrev:Desværre er det bare ikke programmeringsopgaver, men matemtik opgaver, der løses med programmering som regnemaskine. Se fx opgaverne fra sidste år:
http://ncpc.idi.ntnu.no/ncpc2009/ncpc2009problems....
Hvorfor dækker problemerne ikke emner som "minimering af resourceforbrug", "kodens læsbarhed", "low level programming", "high level programmering", etc?
Det har, i mine øjne, intet med programmering at gøre, mindst lige så meget matematik, som du siger. Har lidt svært ved at tage det seriøst, desværre.
Har lige skimmet opgaverne igennem, og det ligner da mere problemregning i folkeren, end programmering.
Men grundlæggende vil jeg da sige, at det har noget med programmering at gøre.
Når man lugter til det første programering på f.eks. HTX, har det næsten altid noget med omregnings "programmer" at gøre. Jeg tror finten er, at de ikke har flere dage til det, så derfor skal det være programmer der er lige til at gå til, og ved at lave en formel, er halvdelen af opgaven løst.
Jeg formoder jo også at de skal kunne lave et lille program hvor man kan ændre attributterne eller variablerne, og derved bliver bedømt for deres opgave...
Men nu skal jeg ikke lege klog på det, jeg er ikke programmør :)
Men grundlæggende vil jeg da sige, at det har noget med programmering at gøre.
Når man lugter til det første programering på f.eks. HTX, har det næsten altid noget med omregnings "programmer" at gøre. Jeg tror finten er, at de ikke har flere dage til det, så derfor skal det være programmer der er lige til at gå til, og ved at lave en formel, er halvdelen af opgaven løst.
Jeg formoder jo også at de skal kunne lave et lille program hvor man kan ændre attributterne eller variablerne, og derved bliver bedømt for deres opgave...
Men nu skal jeg ikke lege klog på det, jeg er ikke programmør :)
#3, #5 og sikkert nogle andre
Jeg tror lige så meget det er et spørgsmål om, hvad man definerer som 'programmering'. Hvad er grænsen mellem programmering, scripting og almindelig tekst-behandling?
ASP/PHP vil jeg mene er programmering. Derfor må HTML også være det. Men hvad med LaTeX? Det er jo samme princip som HTML, med samme resultat som et worddokument, som jeg tvivler på er programmering :-)
Jeg bruger selv opgaver af den type, når jeg lærer nye programmeringssprog, se evt. Projekt Euler, det er meget lignende det her.
Jeg tror lige så meget det er et spørgsmål om, hvad man definerer som 'programmering'. Hvad er grænsen mellem programmering, scripting og almindelig tekst-behandling?
ASP/PHP vil jeg mene er programmering. Derfor må HTML også være det. Men hvad med LaTeX? Det er jo samme princip som HTML, med samme resultat som et worddokument, som jeg tvivler på er programmering :-)
Jeg bruger selv opgaver af den type, når jeg lærer nye programmeringssprog, se evt. Projekt Euler, det er meget lignende det her.
hunn (3) skrev:Desværre er det bare ikke programmeringsopgaver, men matemtik opgaver, der løses med programmering som regnemaskine. Se fx opgaverne fra sidste år:
http://ncpc.idi.ntnu.no/ncpc2009/ncpc2009problems....
Hvorfor dækker problemerne ikke emner som "minimering af resourceforbrug", "kodens læsbarhed", "low level programming", "high level programmering", etc?
Går ud fra, ligesom DDD, at det handler om algoritmik. Altså ikke programmering i den forstand, men mere problemløsning. Det er meget normalt at opgaverne ser sådan ud til sådanne konkurrencer. De tester en i forskellige metoder, og at løse den på den "hurtigste måde" (lavest tidskompleksitet).
Hvordan skulle man i øvrigt vurdere hvilken kode der er flottest? Det er rimeligt individuelt hvordan kode ser bedst ud.
Ja, det er selvfølgelig et præferencespørgsmål. Ligesom når man løser ligninger kan man med div. tricks springe mange af mellemregningerne over. I de fleste tilfælde foretrækker jeg kode hvor strukturen gør det let at finde fejl og omstrukturere. Men det afhænger af opgaven og formålet.
Det er rigtigt nok en algoritmisk programmeringskonkurrence, så det vil være en fordel at have noget kendskab til algoritmik. Det er selvfølgelig korrekt, at programmering handler om meget andet, men meget af det kan være svært, hvis ikke umuligt, at teste i en 5-timers konkurrence, hvor der bruges automatiserede tests af løsningerne. Det skal også lige siges, at konkurrencen ikke kun tester ens evner inden for algoritmik, men også opgaveforståelse, programmering, debugging og holdarbejde, som alle er vigtige evner for programmører.
Et andet godt argument for at bruge denne form for opgaver i en
programmeringskonkurrence er, at mange store internationale virksomheder som f.eks. Google og Microsoft bruger denne slags opgaver i tekniske interviews for at bedømme om folk er dygtige programmører. Det er ud fra den overbevisning, at hvis man er god til at løse den slags opgaver, så er man også en dygtig programmør.
Grunden til at begrænse antallet af sprog er primært historisk. Konkurrencen startede i 1977 (den internationale udgave, ACM/ICPC World Finals, som vinderholdene fra NWERC bliver inviteret til. NWERC er den efterfølgende konkurrence for DM i programmering), hvor man oprindelig kunne bruge C og Pascal. Efterhånden er Java så kommet til, og Pascal er blevet udfaset. En anden grund er, at opgaverne er lavet så, man automatisk kan teste om løsningerne er korrekte og effektive (primært CPU-tid og hukommelsesforbrug). Softwaren på dommermaskinerne skal kunne håndtere alle tilladte sprog, og man skal også sætte fornuftige tidsgrænser for de forskellige sprog. Typisk tillader man dobbelt tid i Java i forhold til C++. Det kan være utroligt svært at sætte en fornuftig tidsgrænse i mange dynamiske sprog som Python og lign., da de ofte kan være op til 30x langsommere (for Python i hvert fald) end C++. Udover det skal der også skrives en løsning til hver opgave i alle de tilladte sprog for at verificere, at det er muligt at løse opgaven inden for de tidsgrænser, man har valgt.
Hvis man gerne vil deltage i en algoritmisk programmeringskonkurrence, hvor man ikke er begrænset af tilladte sprog, kan man prøve kræfte med Google Code Jam. Her er den eneste begrænsning på sproget, at enhver skal kunne få fat på en compiler (eller fortolker) til det.
Deadline for registrering er i øvrigt flyttet til d. 30. september kl. 18.
Sorry for det lange post, men jeg håber, at det svarer på mange af de spørgsmål, der er blevet bragt på banen.
Et andet godt argument for at bruge denne form for opgaver i en
programmeringskonkurrence er, at mange store internationale virksomheder som f.eks. Google og Microsoft bruger denne slags opgaver i tekniske interviews for at bedømme om folk er dygtige programmører. Det er ud fra den overbevisning, at hvis man er god til at løse den slags opgaver, så er man også en dygtig programmør.
Grunden til at begrænse antallet af sprog er primært historisk. Konkurrencen startede i 1977 (den internationale udgave, ACM/ICPC World Finals, som vinderholdene fra NWERC bliver inviteret til. NWERC er den efterfølgende konkurrence for DM i programmering), hvor man oprindelig kunne bruge C og Pascal. Efterhånden er Java så kommet til, og Pascal er blevet udfaset. En anden grund er, at opgaverne er lavet så, man automatisk kan teste om løsningerne er korrekte og effektive (primært CPU-tid og hukommelsesforbrug). Softwaren på dommermaskinerne skal kunne håndtere alle tilladte sprog, og man skal også sætte fornuftige tidsgrænser for de forskellige sprog. Typisk tillader man dobbelt tid i Java i forhold til C++. Det kan være utroligt svært at sætte en fornuftig tidsgrænse i mange dynamiske sprog som Python og lign., da de ofte kan være op til 30x langsommere (for Python i hvert fald) end C++. Udover det skal der også skrives en løsning til hver opgave i alle de tilladte sprog for at verificere, at det er muligt at løse opgaven inden for de tidsgrænser, man har valgt.
Hvis man gerne vil deltage i en algoritmisk programmeringskonkurrence, hvor man ikke er begrænset af tilladte sprog, kan man prøve kræfte med Google Code Jam. Her er den eneste begrænsning på sproget, at enhver skal kunne få fat på en compiler (eller fortolker) til det.
Deadline for registrering er i øvrigt flyttet til d. 30. september kl. 18.
Sorry for det lange post, men jeg håber, at det svarer på mange af de spørgsmål, der er blevet bragt på banen.
#12 greve:
Det er ganske forståeligt, at opgaverne er udformet som de nu engang er - det ærger mig bare en smule, da det ikke er inden for det algoritmiske min stærke(ste) side er :)
Jeg er dog stadig fristet til at samle et hold fra Aalborg, hvis de to andre da ellers gider. Så måske vi får at se...
Det er ganske forståeligt, at opgaverne er udformet som de nu engang er - det ærger mig bare en smule, da det ikke er inden for det algoritmiske min stærke(ste) side er :)
Jeg er dog stadig fristet til at samle et hold fra Aalborg, hvis de to andre da ellers gider. Så måske vi får at se...
vulpus (10) skrev:Ja, det er selvfølgelig et præferencespørgsmål. Ligesom når man løser ligninger kan man med div. tricks springe mange af mellemregningerne over. I de fleste tilfælde foretrækker jeg kode hvor strukturen gør det let at finde fejl og omstrukturere. Men det afhænger af opgaven og formålet.
Strukturen i din kode har intet med hvordan du vælger at behandle beregningerne. God programmering er i min mening solidt algoritmetik implementeret med solidt system arkitektur, programmerings mønstre, lagrings teknologier mv., der resulterer i en så vidt mulig komplet, effektiv og optimal løsning.
Det bedste kode kan ikke løse en algoritme med polynomisk kompleksitet, dog kan en god algoritme formentlig stadig løses med slamkode, så min prioritet er problemet. Selvom jeg dog er absolut besat af arkitektur og mønstre :|
God programmering er dog sjældent det man tjener penge på :\
Gad godt dyste, men har absolut ingen tid :(
hunn (3) skrev:Desværre er det bare ikke programmeringsopgaver, men matemtik opgaver, der løses med programmering som regnemaskine. Se fx opgaverne fra sidste år:
http://ncpc.idi.ntnu.no/ncpc2009/ncpc2009problems....
Hvorfor dækker problemerne ikke emner som "minimering af resourceforbrug", "kodens læsbarhed", "low level programming", "high level programmering", etc?
Kordonme (5) skrev:Det har, i mine øjne, intet med programmering at gøre, mindst lige så meget matematik, som du siger. Har lidt svært ved at tage det seriøst, desværre.
AViGu (6) skrev:Har lige skimmet opgaverne igennem, og det ligner da mere problemregning i folkeren, end programmering.
Jeg synes da at det lyder som om der fokuseres på det fundamentale i programmering.
Et programs formål er at løse en opgave.
Programmørens job er udfra problem at komme frem til et program som løser opgaven.
OOP, patterns, big O analyse, dokumentation er "kun" icing on the cake.
Det er så en ret vigtig icing fordi i den virkelige verden er omkostningerne ved kode vedligeholdelse langt større end omkostningerne ved at skrive koden i første omgang.
Imidlertid kan stort set alle der kan skrive et program der virker også lære at skrive pæn kode (efter lidt grov fil til code reviews), men en pæn del af dem der kan skrive kommentarer, lave pæn indrykning og lære alle GoF patterns udenad kan ikke skrive programmer der virker, fordi de mangler evnen til at gå fra problem til algoritme.
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