Závorky.... LISP na vás! :)
Mě ty závorku chybí, když je v kódu nemám, jsem smutný.
Zivim se tvorbou sw cely svuj zivot.
Živil ses softwarem někdy? Vážně myšleno. Ma to svůj význam.
Tak třeba moje OCD je hluboce znepokojeno, že hrajou neviditelný znaky.
Třeba v C++ má blok i důležitou sémantiku (volání destruktorů), takže ho občas nechceš uplně svazovat s grafickou úpravou kódu. Ale réálně jsem s blokama v Pythonu problěm neměl. Pokračujeme v jazykovejch válkách.
Já tenhle fetiš s definicí bloků nechápu.
pridani neni nahrazeni, ale ok, point taken.
Udelal uz nekdo variantu pythonu, ktera nahrazuje odsazeni chlupatymi zavorkami, nebo tak necim? Protoze dokud bude blok vyznacen odsazenim, odmitam se na tom podilet (jakkoli syntactic sugar ma python udelany hezky).
Jaká? Přesun do jazykových válek?
Python je dobrej na výuku programování pro kohokoliv. Matematici a fyzici tam mají jen bonus navíc.
Python z důvodu velké vhodnosti pro matematické řemeslo? Protože pro programátorské řemeslo to má svá nekoliká úskalí.
DÚ: Naprogramujte iterativně (bez použití rekurze):
a) Binární vyhledávání
b) Quicksort
:-)
Uvidíme za pět až deset let.
Tak si dáme trochu kindergarten informatický teorie. Obecně je rekurze silnější než iterace, nebo taky ekvivalentní, záleží na úhlu pohledu ;-) Rekurze, která se dá napsat jako tail rekurze, je iteraci ekvivalentní, jedno se dá vždy přepsat na druhý. Rozvětvená rekurze se dá na iteraci taky přepsat, ale už je třeba explicitní zásobník nebo jeho ekvivalent. Pokud chceme jako iterativní vs. rekurzivní označovat samotnej problém a ne až implementaci, tak první případ (napr. půlení intervalu) je iterativní, druhej (všechny možný rozměnění bankovky) rekurzivní.
numpy uz je lehce passé. Dneska frci JAX...
Je to rozdíl mezi "rozděl a panuj" a "robím si všechno sám pořád dokola". IMHO to první je mentální konstrukt efektivní v mnoha oborech lidské činnosti, což je IMHO zároveň nejvýznamnější přínos výuky programování na všech úrovních vzdělávacího systému. Rekurzivní problém to není proto, že by to nešlo řešit iterativně (ostatně jsem psal, že Turingův stroj žádný zásobník nemá, takže veškerou rekurzi musí simulovat iterativně), ale proto, že z podstaty problému je vnitřní krok shodný s vnějším, což je vhodné si uvědomit.
Fakt si nejsem jistej, jak to má ten COBOL, ale teoreticky to můžeš udělat tak, že každá funkce má na pevný adrese svou fixní pamět pro parametry, lokálky a návratovou adresu a vybavené. To samozřejmě znamená, že nemůžeš mít obecnou rekurzi, a to ani nepřímou. S trochou péče by šla zaonačit tail rekurze.
A už bysme se na to OT fagkt mohli vysrat :-)
Rekurzivni problem je to jen z jisteho uhlu pohledu, a ten neni nijak nutny. Mozna ho preferuji lide z Computer science, ale pohled, ze mam v mem seznamu dve zarazky, ktere postupne posunuju a priblizuju, neni nijakmene platny.
Turingův stroj žádný implicitní zásobník nemá. Všechno ostatní je jenom omáčka.
Nicméně já jsem narážel na to, že z myšlenkového pohledu je půlení intervalů rekurzivní problém a měl by se tak řešit, čímž by fyzikové a většina matematiků mohla taky v klidu skončit. Do jakých (ne)iterací se to následně kvůli výkonovým optimalizacím a architekturním podmínkám rozepíše pro procesor, nebo jiný HW automat, je problém programátorů překladače/interpretu.
(Já ho teda nikdy neuměl, takovej dědek nejsem, ale vim, že má nějak fixní velikost paměti pro všechny parametry.)
Ne nutně. (Chrly, COBOL, chrchly.)
Už jsme teda silně OT, ale předáváš-li funkci parametry (lhostejno jaké a kam), pak zásobník stejně potřebuješ, ni?
Naopak, pro rekurzi musi byt k dispozici automaticka alokace pameti (zasobnik). Predavani funkci je jen skok na adresu.
No jasně, ale to je něco jiného, řekl bych elementárního.
Fun fact (je to vidět i na tom skenu): výklad funkcí jako argumentů je zařazen až za výklad GOTO.
Za mě jen a pouze Python a to pěkně dva semestry. Však taky "Python is the new Pascal." :-)
A ten Pascal zase neni tak špatnej. Profík samozřejmě radši šáhnul po C++ a nějakym Power Builderu, ale v Delfínech jsem taky dělal nejden rok profi práce. Na desktopový klienty naprosto v pohodě. GUI naklikaný za 10 minut, napsat pár event handlerů, obrazovka hotová za hodinu*. Za chvilku vidíš výsledek, hejbe se to, reaguje to, počítá to. Pokud někdo tvrdí, že webový technologie jsou na výuku lepší, tak upad na hlavu.
*) Zas takovej stachanovec jsem reálně nebyl, nebudu kurvit trh, ale po odečtení internetů a forbesu to sedí :-)
Oni k nemu zas tak casto neprijdou, tohle neni CVUT.
Numpy je hádám na Matlab dobrá průprava.
Fair enough, to by taky šlo. Spíš mi jde o to, aby pak absolventi nepřišli k Matlabu v ostrým prostředí a nekoukali na něj jak péro z gauče.
Tak to snad umel uz FORTRAN 66.
Tak teda dík, no :)
Jsem se na ten zdroják iterací podíval a právě jsem po třiceti letech zjistil, že Pascal umí jako parametry funkcí předávat jiné funkce. Chvíli jsem zapochyboval, zda to není nějaká specialita toho freePascalu, ale není. Uměl to už klasický Pascal. Donutili jste mne z knihovny vytáhnout učebnici z roku 1988 (Jinoch et al., Programování v jazyku PASCAL), je tam tomu věnována přesně stránka a půl, včetně jednoho nekompletního příkladu. No akosi na Gymnáziu (sic!), psal se rok 1991, jsme to tenkrát vynechali.
Matlab prosím rozhodně ne. Sice je tu Octave a v různejch inženýřinách se nepoužívá nic jinýho, ale absolventi by měli mít základy programování. Za mě jen a pouze Python a to pěkně dva semestry. První na ty základy, druhej na numpy, pandas, matplotlib a podobné opičárny.
Což je modus operandi mnoha učitelů nejenom na VŠ. A přímý důsledek přístupu "za našich mladých let byl svět ještě v pořádku".
To jako na CUNI nemají (na to domluvit se) třeba na MATLAB? Přijde mi, že přednášející/cvičící jsou prostě zaseklí na jazyce, v kterým si to oni napsali, a nějaký pokrok za ty roky úspěšně ignorují (což je bohužel modus operandi mnoha předmětů na různých VŠ).
Metoda půlení intervalu iterativně, hukot.
S tím souhlasím, semestr lambda kalkulu a Racketu/Prologu mi IMO daly na pochopení víc než semestr Javy a semestr C++ (kde obojí ve výsledku bylo spíš o tom, jak vypadá enterprise nasazení a struktura, potažmo obsah STL).
Ten posledni odstavec byl prave o tom, ze programovat se tam neuci skoro vubec. V jednom semestru se stihne jen bastleni. Ve kterem jazyku je uz skoro jedno.
Předmět, akademický rok 2021/2022
Programování pro fyziky - NOFY056
Cíl předmětu: Student schopný vyjádřit myšlenku pomocí programovacího jazyka (např. Pascal, C, Fortran).
Poslední úprava: HANYK/MFF.CUNI.CZ (12.04.2008)
https://is.cuni.cz/studium/predmety/index.php?do=predmet&kod=NOFY056a tady máte i zdrojáky (v Pascalu):
http://geo.mff.cuni.cz/~lh/NOFY056/cviceni-2019/
To je strašný. "Matfyz - naučíme vás programovat v jazyce, ve kterým nepíše už ani Nazgúl." :)
Na fyzice ano. Lze je nahradit Pythonem (pojatym velmi prakticky) a jednim dalsim predmetem.
Cywe neříkejte mi, že se na matfyzu furt učí Pascal. To není pravda, že ne?
Ve skutečnost jsou pro výuku programování (ve smyslu myšlení) mnohem lepší funkcionální jazyky. Které jsou navíc i prakticky použitelné ve výzkumu (např. R) :-)
Kdyz uz se o techto vecech bavite ....
http://ipnp.cz/?p=5816Jde hlavne o posledni odstavec.
