Anketa:
Na otázku Váš komentář k předmětu reagovali 24 z možných 98 respondentů, což představuje cca 25% účastníků.

1. Výrazným motivem komentářů je náročnost domácích programovacích úloh. 10 z 16 respondentů, kteří náročnost výslovně zmiňují, soudí, že je vyvážena cekovým přínosem předmětu, zbylí obtižnost jen konstatují nebo ji považují za zbytečně velkou. Tři respondenti si myslí, že předmět by měl být ohodnocen více kredity, dva si myslí, že praktická složka předmětu převažuje natolik, že by měl být ukončen KZ.

2. Pět (5) respondentů uvádí, že by k domácím úlohám ocenili nápovědu/“hinty”, případně dodatečný rozbor na cvičeních.

Reaguju:
Ad 1. Úlohy jsou úmyslně voleny tak, aby (převážně) nebyly triviální. Různí řešitelé mají velmi rozdílnou úroveň své kompetence, strukturovat předmět do několika rozdílných větví tak, aby vyhovoval každé skupině, je nad naše síly. Aktuální stav pokládáme za rozumný kompromis, zřetelně snažší úlohy nebudou přínosem, náročnější mohou odradit i motivovaného začátečníka.

Ad 2. Nesnadný požadavek. Chceme se rozhodně vyhnout “kuchařkám” typu: “Udělejte to takhle a takhle a máte to”, tím by se většina přínosu úlohy vyratila. Větší (i menší) úlohy umožňují různé rovnocenné přístupy, opět, nechceme některé z nich “doporučovat” a upozaďovat jiné. Kromě toho, snadno i autoři úlohy přehlednou některou vlastnost nebo postup, který by se dobře hodil. Dá se uvažovat o modelu: Automatickou součastí každé úlohy je pro autory uvážení, jaké nápovědy, komentáře, odkazy atd. k ní poskytnout a jakým způsobem. Tj. někdy hintů více, někdy méně, někdy nic, někdy rozbor předtím, někdy potom. To jsme zatím nedělali. Prodiskutujeme tuto možnost s kolegy, upozorňuju ale, že co je pro jednoho nápovědou, je pro jiného trivialita a zas pro jiného naprostá mlha…

Anketa:
Na otázku Konkrétní připomínky ke zkouškám … odpovědělo 25 z možných 98 respondentů, což opět představuje cca 25% účastníků.

3. K ústní části zkoušky není větších připomínek, několik respondentů žádá lepší časovou organizaci této části.

4. 16 respondentů považuje praktickou zkoušku za nepřiměřeně obtížnou, 6 respondentů ji považuje za přiměřenou. Kritikové požadují buď její zrušení nebo výrazné zjednodušení zkouškové úlohy.

Reaguju:
Ad 3. Ojedinělé delší čekání na examinátora při více zkoušených (5-10) v posluchárně, se snažíme řešit aktuálně i do budoucna individuálním časovým rozvrhem pro jednotlivce při zkoušce, absolutně hladký provoz neumíme zajistit, početní převaha posluchačů je příliš velká.

Ad 4. Souhlasím se všemi respondenty. Na zkoušku je možno přijít více než třikrát, tím se snažíme kompenzovat nezvyk (nikoli různě vnímaný stupeň obtížnosti úlohy!) řešitelů uvažovat efektivně programátorsky. Jak jsem psal výše, při velmi značném rozdílu kompetencí řešitelů je nemožné sestavit úlohu, kterou budou vnímat všichni stejně. Velmi často potíže při řešení jdou ruku v ruce s teoretickou nepřipraveností, a pak je nezdar v této časti zkoušky spravedlivým výsledkem, i když to tak student většinou nevnímá. Poskytli jsme letos 6 termínů zkoušky a každému, kdo o její splnění usiloval a dával to najevo, jsme vyšli maximálně vstříc.

Jednotlivé zřetelné připomínky z ankety
A. Ciste objektivne se mi nelibi typ ulohy, ktera je v jazyce C, ktery nas OI az do konce semestru vubec neuci, vyrazne lepe resitelna, nez v Jave, se kterou nas docent Jelinek lehce seznamuje jiz od zari. Takove ulohy (byly konkretne dve) mi prisli nefer a do dalsich let bych se jim vyvaroval.

Z pohledu ALG jsou Java a C/C++ zcela ekvivalentní nástroje, schopné srovnatelně efektivně řešit každou úlohu ALG. Referenční řešení, se kterým se studentský kód porovnává, je vždy v Javě. Oba jazyky mají svá pro i proti, žádný z nich nebyl primárně navržen pro řešení algoritmických úloh. V C/C++ je nutno samostatně řešit správu paměti se všemi riziky z toho vyplývajícími, v Javě je nutno dobře rozumět jejím objektovým prostředkům, které mají výraznou tendenci spotřebovávat čas i paměť bez kontroly programátora. Spíše než likvidace zmíněných úloh pomůže zveřejnění vhodné nápovědy k nim, řešili jsme to již v semestru, viz vlákno na fóru ALG.

B. Během semestru jsem měl pár chvil, kdy jsme byl z algoritmizace docela na dně. Obvykle to bývalo kolem čtvrté hodiny ranní…

Zkuste se o úloze a jejím řešení co nejčastěji a co nejvíce bavit s ostatními řešiteli a i dalšími vhodnými osobami již během dne. Líná huba holé neštěstí, jiní mohou mít různé dobré nápady a i Vy máte šanci si leccos ujasnit, když o tom budete nahlas mluvit. Je to standardní mnohokrát potvrzené pozorování.

C. …možná by stálo za to více rozebrat algoritmy prohledávání stavového prostoru, např. Dijkstrův algoritmus pro nalezení nejlevnější cesty, což by mnohým studentům, především začínajícím, kteří o jejich existenci nemají potuchy, velmi pomohlo.

Také jsem příznivcem algoritmů prohledávání stavového prostoru, ale jak vidíte, obsah ALG se mnohým zdá již beztak naplněn po okraj a další přidávání bude obtížné. Řešení vidím v bodě Ad 2. výše, kde by potřebné seznámení bylo součástí komentáře k úloze.

D. Dobře zadané domácí úlohy, ale bodové ohodnocení bylo moc nevyvážené.

To by chtělo přesněji specifikovat, kdy a co bylo nevyvážené. Bodové schéma musíme mít podle Studijního řádu připravené na začátku semestru, během semestru se pak do něj strefujeme úlohami. Obráceně to prakticky nejde, museli bychom mít všechny úlohy hotové, ověřené, atd. před zahájením semestru, na to není nikdy čas.

E. Prakticka programovaci cast je pak desive zlo,… navic ne kazdy je staveny na stresove programovani na cas, i kdyz je vyborny algoritmizator.

I kdyz soucitím s tou emocí, přeci jen musím říci, ze po faktické stránce se mi to po mnoha zkušenostech jeví mnohdy jinak. Nejen výborný ale i “pouze” dobrý a řekněme relativně připravený algoritmizátor se u zkoušky projeví tak, že ví, o co jde, má alespoň približný konstruktivní plán a dokáže ho nějak zdůvodnit, i když mu kód zlobí nebo nechce fungovat. Jeho porozumění pro úlohu a pro vhodný algoritmus je málo závislé nebo vůbec není závislé na momentálních programovacích prostředcích. Pokud se v této fázi dá do řeči se zkoušejícím, zpravidla si vzájemně porozumí a zkoušející ho dokáže vhodně nasměrovat, upozornit na chybějicí obrat, detail apod.

F. Teoretická zkouška byla korektní, asi by ji neuškodilo, kdyby byla přísnější.

Asi bychom si mohli přísnější ústní zkoušku dovolit, kdyby byl poměr počtu studentů a učitelů výrazně menší. Jak plyne z Ad 4. a E., je zřejmé, že určitou část práce teoretické zkoušky koná zkouška praktická, i když to třeba tak na první pohled nevypadá. Kdybychom neměli praktickou část, zadali bychom v teoretické části podobnou úlohu a chěli bychom srozumitelně zdůvodnit algoritmus řešení, volbu datových struktur, složitost. Odhaduju, že výsledná úspěšnost u zkoušky by byla zhruba stejná. Aktuálně práci examinátora s mnohanásobným argumentováním typu “takto Vám to nebude fungovat” zastává Upload System…

G. Nešlo by v rámci praktické části mít i ústní tak, že student by své (třeba i bodově nedostačující) řešení obhájil a prodiskutoval se zkoušejícím, který by mohl body manuálně přidat nebo i uznat řešení za “dostačující” i s malým počtem bodů? Pro studenty by to jistě bylo výhodnější než se hádat s upload systémem, který nepozná, že ke správnému řešení třeba chyběl jen malý krok nebo nepozorné čtení zadání.

Reaguju podobně jako v E, zmiňované “dostačující” řešení je právě to, co mnohdy řešiteli citelně chybí a na jehož absenci se zasekává. Přečtené zadáni konzultujte se zkoušejícím: “Pochopil jsem to takto správně?”, platí přísloví z odpovědi B. Malý chybějící krok, např. omylem přehozenou jedinou podmínku, která vše zboří, jsme běžně schopni odpustit, když to student po zkoušce zjistí, s mírně sníženou klasifikací tak může zkoušku dodatečně “dostat”.

H. Zacne-li clovek implementovat neoptimalni algoritmus, s velkou pravdepodobnosti uz to nestihne zlepsit.

Konzultujte před implementací se zkoušejícím, lepší radu nemám.

I. V nekterych ulohach mi zadani dat prislo az skodolibe zeslozitene (hratky s indexy zabraly hodne casu na ukor vlastniho algoritmu…

O žádných škodolibostech a hrátkách s indexy v zadáních nevím, drobné výpočty jsou samozřejmou a neoddělitelnou součástí algoritmů, na druhé straně vím, že i ty drobné výpočty leckomu dělají potíže, ale to není chyba ani ALG ani jeho učitelů . Případně upřesněte, kde ten problém nastal.

J. Nelíbilo se mi snížení dolní hranice na 4 body. I 5 je málo na normálně fungující program.

Ano. Naštěstí se to většinou týká jen menšiny studentů a to zdaleka ne těch nejlepších, tak to nakonec nebereme jako nějakou velkou škodu nebo demoralizaci…

Připomínky a další diskusi kdykoli uvítáme na našich adresách RNDr. Daniel Průša, Ph.D., RNDr. Marko Genyk-Berezovskyj .