To vypada na prvni pohled dost dobre. My jsme kdysi ve skole pouzivali Maple a Derive (ale jestli jeste tyto SW zijou, to netusim). Dnes asi Mathematica, ale to je moc uzavreny a za penize.
Jak je to s tou integraci do Jupyter Notebooku nebo spis Jupyter Labu?
Julia má pár knihoven pro symbolickou manipulaci, ale Python tady asi vede, hlavně ve výuce, ten to umí i na (programovatelných) kalkulátorech.
Podle me zrovna tohle je oblast, kde se projevi nektere vyhody Julie. Treba to deklarovani symbolu jde pomoci makra elegantneji. Nemusi se predavat nazev retezcem.
24. 5. 2022, 11:31 editováno autorem komentáře
Si ted rikam, ze by to mohlo byt zajimave srovnani moznosti tech knihoven (asi kamen urazu bude integrace predpokladam)
Jaka je v dnesni dobe prednost grafickych kalkulatoru oproti mobilu/tabletu? Ten maly display je dost omezujici. Jedina vyhoda, ktera me napada, ze jde pouzit nekde na stavbe s umazanyma rukama?
24. 5. 2022, 13:40 editováno autorem komentáře
Ano, u zkoušky se přepnou do “exam mode”, aby student neměl přístup k tahákům, co tam pracně nakloval, a může vesele počítat :) Výhoda taky je, že baterka v tom vydrží týdny.
Ta integrace je vyborna. Vystup se vykresluje (snad pouzivam spravny pojem) mnohem hezci nez je v clanku jen z terminalu.
Mozna by bylo hezke taky zminit, ze je mozne pomoci funkce Sympy.latex() dostat vystup primo v latexu pro vlozeni do clanku, dokumentu atp.
Jupyter* bude ukazan v dalsich clancich.
(hmm Derive si pamatuju, to kdysi jelo v DOSu normalne v textovem rezimu a bylo to na jedinou disketu)
Hodi se dodat, ze sympy umi konvertovat vyrazy na jejich odpovidajici reprezentaci v kodu ruznych programovacich jazyku jako treba C, C++, Fortran, Rust, Latex.
sp.printing_ccode(x**2 - y**2) # pow(x, 2) - pow(y, 2)
Pri praci s polynomy a funkcemi expand a factor je dobre si uvedomit, ze operator == neprovadi porovnani na symbolicke urovni, ale na urovni konkretni "instance" vyrazu.
x**2 - y**2 == (x + y)*(x - y) # False
V clanku se pise:
"To je důležité, protože v Pythonu je možné (...) přetížit všechny operátory a umožnit tak zápis výrazů, které již nebudou přímo vyhodnoceny interpretrem (...), ale knihovnou Sympy."
Tohle nemuze byt dobre. Operatory vzdycky vyhodnocuje interpret. A dela to tak, ze se podiva na to, jak je dany operator definovany pro konkretni operandy. Napr. pro "+" se podiva na implementaci funkce __add__ pro konkretni operandy. Jestli jsou operandy cisla, stringy nebo dodane nejakou knihovnou je irelevantni.
vsak ano, v bajtkodu bude instrukce BINARY_ADD, ktera vznikne z tohot +. A interpret se podiva na typ prvniho operandu. Pokud je to treba long nebo float, interpretuje tu instrukci sam, jinak zavola, jak pisete, metodu __add__ pro ten konkretni levy operand.
no ono je to este trocha zlozitejsie, int je ako kazdy iny typ v pythone regulerny objekt. Cize ak napisem a+b tak intretpret tomu rozumie ako a.__add__(b), pripadne ako b.__radd__(a). Cize interpret za vyhodnotenie zodpovedny nie je, za to je zodpovedny konkretny objekt implementujuci dany typ.
24. 5. 2022, 23:31 editováno autorem komentáře
jj je to slozitejsi. Maji tam nekdy "rychlou" cestu bez volani __add__, treba tady https://github.com/python/cpython/blob/3fd86100022103f41ada043f5bb5a7201e80ac27/Python/ceval.c#L2155
Ale popravde - ta evaluace se nejak znecitelnila, pred par lety zrovna ceval.c byl dost dobre citelny zdrojak, ted je tam hodne vyjimek a spec. casu :)
Ne, myslím ten jazyk, co používala NASA pro své vesmírné raketoplány (High-order assembly language/Shuttle), tam se matematické výrazy zapisovaly na několik řádků, exponenty nahoře, indexy dole :)