Super, už se těším na další pokračování.
Měl bych jeden dotaz:
Dá se z toho nakonec nějak vybourat kód kompatibilní s Matlab?
Máte někdo tucha, jak moc ambiciózně to sviští do budoucna oproti Octave?
Julii pouzivam docela casto. Momentalne jsou tam v hroznym srabu grafy, jinak to jde. S matlabem to kompatibilni nijak bejt nema a nechce (narozdil od SciLabu a Octave). Ale da se volat MATLAB externe, vymena datovejch struktur funguje docela hezky. Jestli to nekde neleakuje, to jsem neoveroval, ale asi je to cisty, protoze mi to nikdy neslitlo a to jsem pres to cpal nehorazny mnozstvi dat.
Díky. Nějakou možnost jak volat Matlab scripty jsem na šel na GitHubu, ale měl jsem na mysli spíš něco jako nějaký transpiler do Matlabu, protože používám Simulink a bylo by asi dost na prd dělat půlku v Matlabu a druhou v Juliji, ne tak to ještě takhle spouštět ...
Simulink je skutecne vybornej nastroj a rozumnou nahradu neznam (scicos nebo jak se jmenoval jsem videl v dobach, kdy za nahradu nemohl bejt povazovan i jen pro hnusnost GUI, a to jsem v tomhle hodne tolerantni; mozna mel streva shodny nebo i lepsi nez Simulink, ale neslo se mi pres to prenest). Transpiler je podle me scifi.
Naproti tomu lze volat Julii z C a C (MATLAB) z Julie.
Kdybych mel propojit Julii se Simulinkem, asi bych si napsal v C S-funkci a z ni volal Julii. Podle me by to melo i smysl. Simulink by se postaral o vazbu systemu, ovladaci prvky a vizualizaci a Julie by pocitala.
Jo, to zní rozumně, ale stojí Julie za to? Řekněme že bych počítal max. tak s průměrnými statistickými úlohami, spíše jenom nějaké normalizace dat s využitím i statistických metod, nějaká optimalizace + aplikace algoritmů řízení ?
Taky jsem ridic. Julii zatim nepouzivam na vsechny operace. Podle me za to stoji, jinej nez knihovni kod je brutalne rychlejsi a krome toho je (subj.) mensi mozkozer v tom psat.
V neposledni rade casto vim, ze budu pracovat s necim jinym nez floatem a chci, aby to probihalo nejak inteligentne. Jakmile uz je krome samotny matiky vazba na treba v mem pripade SQL a ProtoBuf, neni co resit, pohodli a lehkost psani oproti matlab/scilab/octave prevazi.
Jeste neco k aplikacim Julie v teorii rizeni a signalu (z nakejch smutnejch asi dejinnejch duvodu si jedou tyhle dva obory napul na svym LTI pisecku, nevim proc). V Julii je zatim jen zakladni DSP tbx (zato, rekl bych, zapocatej velmi slusne -- napr. objekt filtru zda se mi rozumnejsi, nez neobjektovej pristup v klasickym sig.proc.tbx -- umoznuje napr. pustit FIR/IIR filtr na singal nekonecne delky po castech a to syntakticky prijemne). Dale pak, pokud se neco nezmenilo, chybi i to, co je matlabakum znamo jako "control toolbox" a ve skutecnosti je to takovej obal nad knihovnou SLICOT.
Mate-li spetku sil, urcite by stalo za to dostat SLICOT do Julie. SLICOT je zajimavej projekt, ve svem puvodu a podstate open-source, ale jelikoz byl zaprodan (i) do MATLABu, jeho opensourcovatost se vselijak taji a existuji open- i neopen forky. K puvodni verzi a repozitarum se dostat lze a zda se, ze v nem stale probiha puvodni matematickej vyvoj, tj. snad se objevuji i novinky nejen na poli implementacnim. Octave nejakou verzi SLICOTu ma. Zajimavy ovsem je, ze ani MATLAB nepouziva ze 100% fci SLICOTu.
V prvni vlne by bylo bezva, kdyby aspon ten FORTRANskej SLICOT externe volanej v Julii chodil. V nejakem budoucnu by pak asi stalo za to nektery kusy SLICOTu prepsat nativne do Julie, aby chodily ty bigfloaty a tak -- zrovna v teorii rizeni to ma extremne dobrej smysl. (Jedna z mejch motivaci pro Julii byla, ze v bigfloatech sly resit veci se spatne podminenejma systemama, napr. kraceni nul a polu u systemu, kde casovy konstanty mely rozsah nekolika radu -- fakt parada.)
Sam na to bohuzel nemam cas :-( Ale klidne bych se podilel jako kibic/tester/...
Aha, tak to zní zajímavě. No síla by i byla, ale toho času není. SLICOT neznám, aspoň o tom nevím, nejvíce to bude záležet na tom, jestli ho budu potřebovat. Mám začínat vetší projekt, chtěl jsem to dělat v Octave a přemýšlím teď nad tou Julií. Zatím jsem ve stadiu, kdy si ještě můžu vybrat . . .
