Názory k článku SciPy: první seznámení s knihovnou pro vědecké a technické výpočty

V prubehu studii jsem SciPy pouzival hojne, je to opravdu bohata knihovna, ktera bezi i pomerne rychle. Obsahuje ale par skvostu, ze kterych jsem rostl; treba pouziti znaceni sferickych uhlu (θ, φ) v opacne konvenci, nez pouziva zbytek sveta. Ano, nachytal jsem se :(. Nastesti to uz spravili.

otazka autora pro lidi z oboru: jak by tedy mohl vypadat "stack" nekoho, kdo treba nechce pro zpracovani signalu (to je muj obor) pouzivat Julii (ta ujde, IMHO dobry domenove specificky jazyk), Octane nebo R-ko (no to je uplne jazyk mimo chapani vetsiny vyvojaru)? Zakladate to na kombinaci NumPy+SciPy? A jak do toho zapada SymPy, ten totiz hodne pripomina Maple nebo Mathematicu?

Ja pouzivam vsechno, ale je to oproti Maple/Matlabu apod takove trosku dolepovane...

12. 3. 2026, 09:06 editováno autorem komentáře

Já nějak nepochopil otázku asi. Používá se co je a vyhovuje, i kdyby to byl slepenec numpy/scipy/pandas->polars ... . Kdysi na vejšce byla úloha s poli a volné řešení a jelikož třída plná lidí při zaměstnání, to byla přehlídka ..., dokonce i php bylo a jeden si šplhl, že opravdu použil školou protěžovaný matlab.

jasně, jde i o toto - docela dost lidí se mě ptá na vhodný "stack" pro různé oblasti. Já to dovedu dobře posoudit pro oblast zpracování signálů a modelování. Takže například kombinace NumPy+SciPy+Mat­plotlib pro první oblast a NumPy+Pandas(Po­lars)+scikit-learn+řekněme Seaborn pro oblast druhou.

Zajímá mě, jak to mají ostatní v jejich oborech. Protože jasně "používá se co je a vyhovuje", ale to taky může znamenat hodně času stráveného ve slepé uličce (to jsem viděl, když jeden pán vlastně pracně reimplemenoval SciPy). Předpokládám, že někdo z oblasti teoretické matiky/fyziky zkouší SciPy, ale je to dostatečně dobré pro práci, nebo se musí jít do komerčního SW? Matlab už tady pan kolega zmiňoval (a jeho nespornou výhodou je, že se učí na školách). A podobné otázky...

> Předpokládám, že někdo z oblasti teoretické matiky/fyziky zkouší SciPy, ale je to dostatečně dobré pro práci, nebo se musí jít do komerčního SW?

Moje zkusenost z (teoreticke) fyziky pevnych latek je takova, ze SciPy postacovalo na vyuku a vetsinu vypocetne nenarocnych uloh. Jakekoli narocnejsi, "produkcni" vypocty vedouci k publikaci bezeli ve Fortranu nebo v nejake specializovane C++ knihovne, neco jako ALPS . Pozdeji jsem vidal i programy v Julii, hlavne od lidi z USA.

Neznam jedineho vedce, ktery by pro symbolicke vypocty pouzival SymPy. Zahranicni vedci meli z 90% Mathematicu, ktera se casto dala pouzit i pro narocnejsi numericke vypocty. Ve vysledku nahradila SciPy, Fortran i Maple. Dost jsem jim na konferencich zavidel, u nas nebyly licence.

Dnes delam elektronovou mikroskopii, tam to hodne stoji na komercnim SW. Osobne mam rad Julii a Python se Scipy a Numpy jsem uplne opustil.

12. 3. 2026, 12:48 editováno autorem komentáře

Dik!

ja se drzim furt c, c++ i fortranu :-)

Ja delam zpracovani velmi presnych mereni a velmi presnych signalu pro nizsi frekvence (do 1 MHz), a tak nejak vsichni zahranicni kolegove (ti co delaji algoritmy, pripadne simulace mereni), jedou v Matlabu, pripadne par osvicenejsich preslo na GNU Octave. Vtipne je, ze ti co pracuji s frekvencema 1 Ghz a vyssi, tak jedou skoro vyhradne v numpy a scipy.
A nejzajimavejsi na tom je ze to ani nevadi, protoze tyhle dva svety se kapanek miji - pomale frekvence se proste pocitaji a meri vyrazne jinak nez vysoke, takze i algoritmy jsou uplne jine.

Ech, mel jsem to napsat do jineho vlakna...

12. 3. 2026, 20:59 editováno autorem komentáře

Taky dik, dobre vedet.

Můj hlavní obor je teorie dynamických systémů (zpětnovazební řízení, identifikace atd.). Jako fanda open source bych si hrozně přál nahradit komerční Matlab nějakým Python stackem. Ale bohužel ta neuvěřitelná "out-of-boxnost" Matlabu a ta pohodlnost mít všechno na jednom místě a nepřemýšlet nad tím jako nad rozdílnými věcmi je za mě nenahraditelná... Musím zdůraznit, že bohužel. A i když by to s trochou práce asi šlo, tak už vůbec nic mi nenahradí Simulink, což je tool pod Matlabem pro grafikcé modelování. A kombinace skriptování plus grafického modelování je prostě (pro mě) top...

Diky!

hmm Simulink, to jsem ted videl, ze pouzivaji na uni a vypada to (zdalky) hodne pouzitelne

rád by som upozornil na PathSim a PathView ktoré teraz pred pár mesiacmi vydal Milan Rother a hlavná idea je modelovanie systémov ako v Simulinku, je to celé naprogramované v pythone
https://milanrother.com/
https://view.pathsim.org/?theme=dark

Na první pohled to vypadá skvěle, díky za odkazy.

Pání! Díky za tip, určitě se podívám.

Data z měření (typicky tlaky, teploty, příkony) zpracovávám pandas, numpy, matplotlib (původně jsem používal matlab, pak R a následně přešel k pythonu). Jinak k tomu ještě trochu simulování - pouštím si fmu z Modelica (fmpy)... Z toho zase lezou data typu tlak teplota.... Semtam použiju aj nějaké pšouky ze scipy (optimize, interpolate) ...A k tomu všemu potřebuju teda ještě i fyzikální vlastnosti, to je ale komerční, licencovaná záležitost.

Dik!

Poměrně často pracuji s obrazovými daty ze spektrální počítačové tomografie a s daty z gama spektrometrie. Pojem „stack“ proto chápu poněkud šířeji. Při vývoji nového softwaru pro zpracování dat nejprve problém konzultuji s generativní AI. Ta mi umožní zpřesnit vágní specifikaci úkolu a navrhnout "state-of-the-art" řešení.

Následující kroky závisí na rozsahu řešení. Pokud jde o menší projekt, pomocí AI vygeneruji instrukce pro kódovacího agenta, který vytvoří celý projekt včetně výpočetních skriptů. V případě rozsáhlejšího projektu jsou instrukce pro kódovacího agenta dávkovány postupně. Poté následuje kontrola kódu, generování a spouštění testů a následné úpravy kódu. Vzhledem k tomu, že nejnižší chybovost kódu generovaného AI je podle dostupných informací u Pythonu, výsledkem často bývá použití knihoven SciPy a NumPy.

Vlastní generování kódu provádím ve Visual Studio Code pomocí Codexu (placená verze od OpenAI). Před změnami provedenými pomocí Codexu kód archivuji pomocí Gitu. Pokud Codex kód pokazí (což se občas stává), lze jej snadno vrátit do předchozího stavu. Pro trvalé Git commity používám squashing.

Samozřejmě pracuji i se staršími kódy v MATLABu, protože kolegové jsou na ně zvyklí. MATLAB se původně masivně vyučoval v inženýrských studijních programech. Firmy si však začaly stěžovat, že MATLAB ve svých produktech již tolik nepoužívají a že od absolventů očekávají znalost Pythonu. I když se studenti o MATLABu stále ještě něco učí (Simulink), Python je nyní hlavním jazykem.

Shrnutí: V mém případě je použitý „stack“ velmi často určen tím, co doporučí generativní AI na základě požadavku na použití „best coding practices“ v daném případě.

Pro zajímavost ještě uvedu, že současní studenti často dělají chyby při převodu fyzikálních jednotek (nejsou zvyklí počítat.) scipy.constants to řeší, protože například hodnotu mass stopping power 2 MeV·cm²/g mohou zapsat 2 * s.mega * s.eV * s.centi**2 / s.milli. Výsledek výpočtu dostanou v SI jednotkách.

Za mechaniku kontinua bych to shrnul asi tak, že python je často jako preferované rešení. Býva to i hlavní skriptovací jazyk v komerčních SW (BetaCAE, ABAQUS/CAE...).
Použití scipy se nabízí jako dobrý "Švýcarský nožík" na předzpracování vstupů, nebo vyhodnocení výstupů. Vlastní solvery však mají střeva Fortran/C++.

Licence je v pohodě takže to máme zadrátováno i v našich korporátních produktech.
Současně spousta knihoven má závislost na Scipy, takže když tam je, proč ji nevyužít?
Osobně nejvíc používám
- Scipy.optimize
- Scipy.interpolate pro práci na křivkách z měření
- RBF interpolator pro surogatni modely
- Scipy.stats okrajově ... to už pak kdyžtak směřuji ke scikit-learn

Ale obecně si myslím, že by se svět bez Scipy točil o dost pomaleji, už jenom těch závislostí (zmíněný scikit-learn s spousta jiných), takže si myslím že Scipy má ve finále 99,9% kolegů aniž by věděli o tom, že to vůbec používají.

dobre receno.