Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Patyk 19. 09. 2015, 20:56:22
-
Potřebuju naimplementovat několik matematických výpočtů, vesměs nějaké HMM a nezávisle na tom SAT. Budu to pouštět na počítači s několika jádry a 32-64 GB paměti. Jaký jazyk byste doporučili? Umím obstojně C++ a Javu (a C#, to ale asi na Linux moc není). HMM potřebuje spíš paměť a SAT zase spíše rychlost výpočtu. Kamarád tvrdí, že je to v podstatě jedno, ale existují nějaká kritéria (pro uvedené úlohy), jaký jazyk zvolit?
-
Pro HMM bych zvolil Octave. Pro daný účel se mi jeví jako nevýkonnější a zároveň nejpohodlnější.
-
Se SAT se nepis, na to existuje kupa solveru. HMM mozna jo, ale i tak zalezi co delas. Jestli delas jen nejakou aplikaci, snaz se vyhnout tomu si to programovat sam.
Jestli je to skolni uloha (tedy podstatou je vlastni implementace), pouzil bych (byt tebou) C++.
A jestli chces jen neco napocitat, delej to v Pythonu nebo te Octave, usetris si nervy.
-
Matlab/octave ačkoli se někdy může zdát, že je to jak s dělem na komáry, bývá ve výsledku nejvhodnější a spolehlivá cesta.
A pokud by tam něco opravdu nevyšlo (výkonem-časově, ...), je možné nejen dělat externí moduly (nevím jak octave), ale i udělat export, spustit c++ (resp. libovolný) program, naimportovat, upravit, vyplivnout a výsledek se zase naimportuje do matlab. Jako nejzazší fallback.
-
Na matematicke vypocty je klasicky najlepsi Fortran.
-
Kto nie je schopny (alebo sa mu nechce) zvladnut Fortran moze pouzit systemy ala Matlab
Bol tu sice doporucovany len system Octave:
https://www.gnu.org/software/octave/
Ale ja som pouzival v minulosti Scilab, pretoze vtedy bol bilzsie k Matlabu ako Octave (neviem aky je stav teraz)
http://www.scilab.org/
Najlepsie nainstaluj si obidva a porovnaj co ti viac vyhovuje.
alebo SciPy
http://www.scipy.org/
existuju este rozne free CAS systemy ako:
http://maxima.sourceforge.net/
http://www.sagemath.org/
Ma to interaktivny notebook a neviem ako sa v tom da nieco naprogramovat
-
Umím obstojně C++ a Javu (a C#, to ale asi na Linux moc není).
Neumíš nic z toho, akorát marníš nanicovatě čas na diskuzích. V opačném případě by to již dávno bylo vypočítáno.
-
Umím obstojně C++ a Javu (a C#, to ale asi na Linux moc není).
Neumíš nic z toho, akorát marníš nanicovatě čas na diskuzích. V opačném případě by to již dávno bylo vypočítáno.
Tak to je drastická odpověd, nicméně může být pravdivá.
-
Umím obstojně C++ a Javu (a C#, to ale asi na Linux moc není).
Neumíš nic z toho, akorát marníš nanicovatě čas na diskuzích. V opačném případě by to již dávno bylo vypočítáno.
Tak to je drastická odpověd, nicméně může být pravdivá.
Nereagujme na debilní troly.
-
Se SAT se nepis, na to existuje kupa solveru. HMM mozna jo, ale i tak zalezi co delas. Jestli delas jen nejakou aplikaci, snaz se vyhnout tomu si to programovat sam.
Jestli je to skolni uloha (tedy podstatou je vlastni implementace), pouzil bych (byt tebou) C++.
A jestli chces jen neco napocitat, delej to v Pythonu nebo te Octave, usetris si nervy.
Doporučuju Minisat, je to napsané v C, takže to jde volat z čehokoliv. Python bych asi neriskoval, C++ je pro HMM lepší volba.
-
Na matematicke vypocty je klasicky najlepsi Fortran.
S tím plně souhlasím.
Nechápu, jak někdo může doporučit C++, které se na matematické výpočty nehodí, protože je příliš univerzální. Vždyť ani neumí vynásobit pole konstantou, neumí pracovat s komplexními čísly, neumí přeskupit řádky/sloupce v maticích...
-
Nemůžu doporučit z vlastní zkušenosti, protože jsem to nikdy nepoužíval, ale každopádně v Rku existují na oboje knihovny:
- http://reasoning.cs.ucla.edu/rsat/papers/rsat_2.0.pdf
- https://cran.r-project.org/web/packages/HiddenMarkov/HiddenMarkov.pdf
- https://cran.r-project.org/web/packages/depmixS4/vignettes/depmixS4.pdf
Pokud by ses rozhodl použít Rko, tak silně doporučuju jako první krok dobře pročíst a dobře vyzkoušet tohle: http://www.johndcook.com/blog/r_language_for_programmers/ Pokud na něj totiž půjdeš s programátorským předporozuměním, tak si vytrháš všechny vlasy, je to (pro programátora) poněkud nezvyklý jazyk :)
Taky je u Rka potřeba myslet na to, že ten samotný jazyk je pomalý, takže se používat jenom pro "high-level" manipulace s daty, vlastní implementace těch operací je už rychlá. Ale to je podobné i s Pythonem.
-
Na matematicke vypocty je klasicky najlepsi Fortran.
Přesně tak, pro tohle Fortran vznikl a dodnes to dělá nejlépe ze všech.
-
Na matematicke vypocty je klasicky najlepsi Fortran.
Přesně tak, pro tohle Fortran vznikl a dodnes to dělá nejlépe ze všech.
Fortran je ovsem jazyk znacne staricky, nekdy z doby, kdy mel Zizka jeste obe oci. Jestlipak se od dob sveho vzniku aspon trochu zmodernizoval? Jestli se nahodou dodnes nepouziva hlavne proto, ze jsou pro nej knihovny snad uplne na vsechno, co by cloveka mohlo napadnout.
-
Na matematicke vypocty je klasicky najlepsi Fortran.
Přesně tak, pro tohle Fortran vznikl a dodnes to dělá nejlépe ze všech.
To je hlavně o knihovnách, a ty existují ve většině jazyků. Než se učit Fortran, je lepší vzít C++ nebo Javu a naučit se používat nějakou dobrou knihovnu.
-
Fortran je ovsem jazyk znacne staricky, nekdy z doby, kdy mel Zizka jeste obe oci. Jestlipak se od dob sveho vzniku aspon trochu zmodernizoval? Jestli se nahodou dodnes nepouziva hlavne proto, ze jsou pro nej knihovny snad uplne na vsechno, co by cloveka mohlo napadnout.
Samozřejmě byl zmodernizován, dokonce několikrát. Stále je však zpětně kompatibilní - je to nezbytně nutná podmínka pro všechny jeho modernizace.
Fortranské knihovny jsou dodnes používány v ostatních jazycích - včetně céčka.
To je hlavně o knihovnách, a ty existují ve většině jazyků. Než se učit Fortran, je lepší vzít C++ nebo Javu a naučit se používat nějakou dobrou knihovnu.
Ne. To, co mají ostatní jazyky v knihovnách, to má Fotran již v syntaxi jazyka. Například prohození dvou řádek či sloupců v tabulce se dělá přiřazovacím příkazem. Funkce abs(komplexní_číslo) dodá přesně to, co se od ní očekává - délku vektoru. V tom mu může konkurovat snad jen Python. C++ ani Java se v této oblasti prostě nechytají.
-
https://www.bing.com/search?q=mathematica%20hmm&form=EDGENT&qs=PF&cvid=3c0e4c0779b14137939bb1470ed988c3&pq=mathematica%20hmm
http://demonstrations.wolfram.com/TheSatisfiabilityThreshold/
-
Fortran je ovsem jazyk znacne staricky, nekdy z doby, kdy mel Zizka jeste obe oci. Jestlipak se od dob sveho vzniku aspon trochu zmodernizoval? Jestli se nahodou dodnes nepouziva hlavne proto, ze jsou pro nej knihovny snad uplne na vsechno, co by cloveka mohlo napadnout.
Samozřejmě byl zmodernizován, dokonce několikrát. Stále je však zpětně kompatibilní - je to nezbytně nutná podmínka pro všechny jeho modernizace.
Fortranské knihovny jsou dodnes používány v ostatních jazycích - včetně céčka.
To je hlavně o knihovnách, a ty existují ve většině jazyků. Než se učit Fortran, je lepší vzít C++ nebo Javu a naučit se používat nějakou dobrou knihovnu.
Ne. To, co mají ostatní jazyky v knihovnách, to má Fotran již v syntaxi jazyka. Například prohození dvou řádek či sloupců v tabulce se dělá přiřazovacím příkazem. Funkce abs(komplexní_číslo) dodá přesně to, co se od ní očekává - délku vektoru. V tom mu může konkurovat snad jen Python. C++ ani Java se v této oblasti prostě nechytají.
Že to je v syntaxi jazyka není zrovna výhoda.
-
Že to je v syntaxi jazyka není zrovna výhoda.
Jak kdy. Rko má třeba oproti Pythonu výhodu, že některý často používaný obraty jsou přímo zabudovaný nebo je jazyk umožňuje svou dynamičností. Oproti tomu v Pythonu se to musí nějak obcházet, protože s tím jazyk nepočítal.
Např. Python neumožňuje nevyhodnotit parametr funkce/metody. Když to chci udělat, musím to složitě obcházet přes lambdy nebo nějaký jiný nepřirozený wifikundace. Např. v Rku můžu napsat ("day" je název sloupce v dt, který má typ data.table):
dt[day==1,]
V pythonu věci tohodle typu nejdou, protože by se snažil "day" vyhodnotit.
-
Že to je v syntaxi jazyka není zrovna výhoda.
Jak kdy. Rko má třeba oproti Pythonu výhodu, že některý často používaný obraty jsou přímo zabudovaný nebo je jazyk umožňuje svou dynamičností. Oproti tomu v Pythonu se to musí nějak obcházet, protože s tím jazyk nepočítal.
Např. Python neumožňuje nevyhodnotit parametr funkce/metody. Když to chci udělat, musím to složitě obcházet přes lambdy nebo nějaký jiný nepřirozený wifikundace. Např. v Rku můžu napsat ("day" je název sloupce v dt, který má typ data.table):
dt[day==1,]
V pythonu věci tohodle typu nejdou, protože by se snažil "day" vyhodnotit.
Jo, ale R je spíše DSL. Myslím, že zrovna pro HMM (a už vůbec ne pro SAT) není matematická syntax potřeba.
-
To je hlavně o knihovnách, a ty existují ve většině jazyků. Než se učit Fortran, je lepší vzít C++ nebo Javu a naučit se používat nějakou dobrou knihovnu.
Ne. To, co mají ostatní jazyky v knihovnách, to má Fotran již v syntaxi jazyka. Například prohození dvou řádek či sloupců v tabulce se dělá přiřazovacím příkazem. Funkce abs(komplexní_číslo) dodá přesně to, co se od ní očekává - délku vektoru. V tom mu může konkurovat snad jen Python. C++ ani Java se v této oblasti prostě nechytají.
Že to je v syntaxi jazyka není zrovna výhoda.
[/quote]
To je pouhé tvrzení, které nemá žádný důkaz ani hodnotu. Až příliš často se setkávám se zaslepeným propagováním C++, C# či Javy bez ohledu na use case.
-
Jo, ale R je spíše DSL. Myslím, že zrovna pro HMM (a už vůbec ne pro SAT) není matematická syntax potřeba.
Ne, ne, R je svébytný jazyk s pár zajímavými vlastnostmi (např. scope implementovaný přes environmenty), vlastním objektovým systémem (resp. dvěma ;) ) atd.
-
... Myslím, že zrovna pro HMM (...) není matematická syntax potřeba.
Pro matematiku není matematická syntax potřeba? Povídej, to zní zajímavě.
-
Na matematiku Fortran. I přes počáteční nechuť nám ho na fakultě před 15 lety nacpali do hlavy (F77 obligátně a F90 v rámci projektů, jichž jsme se účastnili) a s odstupem času musím uznat, že věděli proč.
Že je v něm spousta věcí součástí jazyka a ne jen v knihovnách je značná výhoda. Například v tom, že překladač přesně ví, co po něm programátor chce, a přeloží to jak nejlépe umí.
Že má bezkonkurenční matematické a technické knihovny je obrovské plus. V těch knihovnách totiž po těch desítkách let používání už prakticky nejsou žádné chyby a jsou vymazlené k dokonalosti. A zrovna chyby ve výpočtech se brutálně těžko objevují, protože narozdíl od jiných chyb, kdy vám třeba jednou za 100 spuštění spadne program, tady nic nepadá, jen z něj občas vypadne trochu špatný výsledek, který se dá ověřit jedině tak, že ho přepočítáte jinak a jinde. Což může být s ohledem na problémy, které se ve Fortranu řeší, dost značný problém (např. není k dispozici jiný superpočítač a jiný člověk, který by to napsal jinak).
Fortran samozřejmě byl mnohokrát modernizován. Problém je, že ho odsuzují lidé, kteří v něm v životě nenapsali ani řádku. Technické výpočty se v něm dělají velmi přímočaře a pohodlně. V tom mu můžou konkurovat snad jedině jazyky jako je Python, ovšem s tím, že jim chybějí ta kvanta kvalitních knihoven a jsou několikanásobně pomalejší. Což může být u výpočtu trvajícího týden dost zásadní problém.
-
Nic, ja Fortran neodsuzuji, jen vyzvidam, jak to vypada dnes. Ja ho videl naposledy na VS na jakemsi starickem ICL s terminaly z IQ 151, kde se klavesy musely zatloukat kladivem. A pamatuji fortranackou historku, jak Amikum pry spadla jakasi druzice, protoze pri derovani pasky s programem vypadla v cyklu carka a protoze Fortran tehdy (nevim, jak dnes) nemel deklaraci promennych, tak to kompilatoru nevadilo a na drahy pruser bylo zadelano. Jo, takova carka nekdy dela divy.
-
Nechápu, jak někdo může doporučit C++, které se na matematické výpočty nehodí, protože je příliš univerzální. Vždyť ani neumí vynásobit pole konstantou
std::valarray?
, neumí pracovat s komplexními čísly
std::complex?
, neumí přeskupit řádky/sloupce v maticích...
Pravda, matice nejsou ve standardní knihovně. Je třeba stáhnout jednu z hromady dobrých knihoven.
-
Jo, ale R je spíše DSL. Myslím, že zrovna pro HMM (a už vůbec ne pro SAT) není matematická syntax potřeba.
Ne, ne, R je svébytný jazyk s pár zajímavými vlastnostmi (např. scope implementovaný přes environmenty), vlastním objektovým systémem (resp. dvěma ;) ) atd.
Jo, ale používá se více mimo "data science"?
-
Že to je v syntaxi jazyka není zrovna výhoda.
Jak kdy. Rko má třeba oproti Pythonu výhodu, že některý často používaný obraty jsou přímo zabudovaný nebo je jazyk umožňuje svou dynamičností. Oproti tomu v Pythonu se to musí nějak obcházet, protože s tím jazyk nepočítal.
Něco se jistě hodí, když se to nepřežene, ale prakticky vše lze nějak zabudovat do knihovny. Například v jazycích s přetížením operátorů si můžu udělat fortranovské ** a spoustu jiných operátorů pro vektory, matice, tenzory a kdejaké jiné objekty.
-
Nic, ja Fortran neodsuzuji, jen vyzvidam, jak to vypada dnes. Ja ho videl naposledy na VS na jakemsi starickem ICL s terminaly z IQ 151, kde se klavesy musely zatloukat kladivem. A pamatuji fortranackou historku, jak Amikum pry spadla jakasi druzice, protoze pri derovani pasky s programem vypadla v cyklu carka a protoze Fortran tehdy (nevim, jak dnes) nemel deklaraci promennych, tak to kompilatoru nevadilo a na drahy pruser bylo zadelano. Jo, takova carka nekdy dela divy.
Všichni fortranští programátoři dnes píší v deklaraci IMPLICIT NONE. Tím se zapne povinná deklarace proměnných. A nebylo to vypadením čárky, ale její záměnou za tečku. Tím se z cyklu stalo obyčejné přiřazení. Ve výpisu programu to vypadalo skoro stejně.
Dnes se ve Fortranu nepoužívá ani nechvalně známé GOTO - jsou tam běžné řídicí struktury jako v ostatních jazycích - tuším už od roku 1977. Dokonce se v moderním Fortranu dá programovat objektově.
Zajímavostí Fortranu je, že nemá žádná vyhrazená slova. Proměnná se klidně může jmenovat "if" nebo "goto". Je to však spíš recept pro sebevrahy. Na druhou stranu se programátor nemusí učit klíčová slova, která nepoužívá.
Co ostatním jazykům chybí, tak číslování indexů polí od jedné, resp. si mohu stanovit libovolný počáteční a koncový index. Spousta programátorů si ani neuvědomuje, kolik zla už napáchalo povinné číslování indexů polí od "0".
Fortran je dnes součástí běžných linuxových distribucí. Příkaz "apt-search fortran" mi vyhodil 366 položek, což není málo. Jsou v tom různé verze kompilátoru i knihoven - stačí si jen vybrat.
-
Technické výpočty se v něm dělají velmi přímočaře a pohodlně. V tom mu můžou konkurovat snad jedině jazyky jako je Python, ovšem s tím, že jim chybějí ta kvanta kvalitních knihoven a jsou několikanásobně pomalejší.
Co má Python oproti jiným jazykům aby se v něm "velmi přímočaře a pohodlně dělaly technické výpočty"?!
Jo, ale používá se více mimo "data science"?
Ne, ale chtěl jsem tím říct, že to je skutečně programovací jazyk, ne jenom nějaké DSL pro vyjádření něčeho doménově specifického a omezeného. Rko je univerzální a dá se v něm napsat cokoli včetně http serveru, akorát to moc lidí nenapadne dělat :)
Například v jazycích s přetížením operátorů si můžu udělat fortranovské ** a spoustu jiných operátorů pro vektory, matice, tenzory a kdejaké jiné objekty.
To sice jo, ale to, co jsem psal, neudáláš skoro nikde. Např. ggplot2 to masivně využívá:
> head(counts)
dow hour value count
1: 2 22.50 0 659
2: 2 22.75 0 695
3: 2 23.00 0 707
4: 2 23.25 0 719
5: 2 23.50 0 773
6: 2 23.75 0 764
> ggplot(counts)+geom_line(aes(x=value,y=count*2,color=dow))
- všimni si toho "count*2" - to je parádička, pracuju se sloupcem (count není proměnná) a v klidu s ním můžu dělat matematické operace! Tohle prostě v Pythonu jednoduše neuděláš.
-
Tohle prostě v Pythonu jednoduše neuděláš.
P.S. šlo by to pomocí maker, ale ta python bohužel taky nemá...
-
Potřebuju naimplementovat několik matematických výpočtů, vesměs nějaké HMM a nezávisle na tom SAT. Budu to pouštět na počítači s několika jádry a 32-64 GB paměti. Jaký jazyk byste doporučili?
Jednoznačně MATLAB, je polopatický a tak jednoduchý, že jej pochopí i absolvent IT. Pro matematiky je to ovšem urážka cti.
-
Potřebuju naimplementovat několik matematických výpočtů, vesměs nějaké HMM a nezávisle na tom SAT. Budu to pouštět na počítači s několika jádry a 32-64 GB paměti. Jaký jazyk byste doporučili?
Jednoznačně MATLAB, je polopatický a tak jednoduchý, že jej pochopí i absolvent IT. Pro matematiky je to ovšem urážka cti.
Však jsme mu už doporučovali Octave, ale toho sis asi nevšiml.
-
Tohle prostě v Pythonu jednoduše neuděláš.
P.S. šlo by to pomocí maker, ale ta python bohužel taky nemá...
Pythton makra _naštěstí_ nemá.
-
Fortran je ovsem jazyk znacne staricky, nekdy z doby, kdy mel Zizka jeste obe oci. Jestlipak se od dob sveho vzniku aspon trochu zmodernizoval?
...
Ano dost sa zmodernizoval.
Pocas VS v 90 rokoch minuleho storocia sme na numerike pouzivali F77. Teraz je bezny standard F90, 95 a je to uz o dost modernejsie ako predtym. K dispozicii su free kompilatory gfortran a g95.
-
Hele, já nevím, školy nemám. Ale je fakt tak podstatné vybírat jazyk? Výkon aplikace v běžné praxi stejně nejvíce závisí na kvalitě programátora a jeho znalosti daného jazyka, než na samotném jazyce.
Z dotazu víme, že toho víme velmi málo. Obecný typ úlohy (HMM, SAT). O náročnosti konrétní instance úlohy/modelu nevíme vůbec nic. Nevíme, jestli výpočet musí splňovat nějaká (pseudo)realtimová kriteria. Hlavně že víme na jakém HW výpočet poběží.
Takže můžeme říct, že z dotazu (z toho jak a kde byl položen) víme vlastně docela dost - tazatel není v oboru (implementace num. mat.) zběhlý.
Takže IMHO jediná správná odpověď zní - napiš to v jazyce, který umíš. C++ i Java nepochybně zvládnou to, co potřebuješ. Zvládne tvůj SW v Javě nebo v C++ běžet na tvém HW? To nikdo neví. A nikdo ani neví, jestli by zvládl běžet, kdyby ses půlrok učil Fortran a napsal to v něm. Nikdo neví, jestli sis z neznalosti nezvolil úlohu, kterou by neutáhl žádný dostupný HW na planetě.
Ber ten program v Javě nebo v C++ jako podrobnou analýzu problému. A pokud se ukáže, že se to v tom jazyce nedá rozběhnout (a není to tím, že to neumíš ty) a nedá se posílit HW, tak se může řešit v jaké verzi Fortranu to psát.
A samozřejmě je potřeba rozmýšlet, co má smysl psát a na co použít hotové odladěné knihovny. Ale to je tak triviální a obecně platná rada, že je mi až hanba to psát.
-
Ber ten program v Javě nebo v C++ jako podrobnou analýzu problému. A pokud se ukáže, že se to v tom jazyce nedá rozběhnout (a není to tím, že to neumíš ty) a nedá se posílit HW, tak se může řešit v jaké verzi Fortranu to psát.
No, aby se s tou Javou vesel do pameti. Fortran kdysi jel na strojich s 256 MB pameti (kurva, to tehdy bylo ale pameti!) a o vykonu silne zastaraleho PC a pritom se v tom delaly dost narocne veci.
-
Ber ten program v Javě nebo v C++ jako podrobnou analýzu problému. A pokud se ukáže, že se to v tom jazyce nedá rozběhnout (a není to tím, že to neumíš ty) a nedá se posílit HW, tak se může řešit v jaké verzi Fortranu to psát.
No, aby se s tou Javou vesel do pameti. Fortran kdysi jel na strojich s 256 MB pameti (kurva, to tehdy bylo ale pameti!) a o vykonu silne zastaraleho PC a pritom se v tom delaly dost narocne veci.
Nevíme na jak dlouhou cestu se chce někdo vydat autem, ale budeme ho zrazovat, že s normálním autem s 50litrovou nádrží by tam taky nemusel dojet, že jiná specializovaná expediční auta si vezou třeba 400 litrů paliva.
A pak se ukáže, že ten člověk třeba chtěl buď dojet autem do Antarktidy, nebo chtěl dojet jenom 30 km do okresního města...
-
Tohle prostě v Pythonu jednoduše neuděláš.
P.S. šlo by to pomocí maker, ale ta python bohužel taky nemá...
Pythton makra _naštěstí_ nemá.
Co si predstavujes pod pojmem makro?
-
Pythton makra _naštěstí_ nemá.
Co si predstavujes pod pojmem makro?
Například jako nějakou alternativu #define v céčku. Máš nějakou vhodnější definici? Co třeba lispové makro? To by bylo zajímavější.
Pokud máš na mysli importy, tak to nejsou makra.
-
Například jako nějakou alternativu #define v céčku. Máš nějakou vhodnější definici? Co třeba lispové makro? To by bylo zajímavější.
Pokud máš na mysli importy, tak to nejsou makra.
Tak vždycky se dá použít cpp a nějakej build script/makefile
-
... Ale je fakt tak podstatné vybírat jazyk? Výkon aplikace v běžné praxi stejně nejvíce závisí na kvalitě programátora a jeho znalosti daného jazyka, než na samotném jazyce.
Výkon se dnes už tolik neřeší. Spíš vhodnost jazyka k danému účelu. Tedy tak, aby se ta aplikace dobře psala, dobře udržovala a schovalo se do ní co nejméně chyb. Šetří se tedy hlavně čas programátora.
Takže IMHO jediná správná odpověď zní - napiš to v jazyce, který umíš. C++ i Java nepochybně zvládnou to, co potřebuješ. Zvládne tvůj SW v Javě nebo v C++ běžet na tvém HW? To nikdo neví. A nikdo ani neví, jestli by zvládl běžet, kdyby ses půlrok učil Fortran a napsal to v něm. Nikdo neví, jestli sis z neznalosti nezvolil úlohu, kterou by neutáhl žádný dostupný HW na planetě.
Ber ten program v Javě nebo v C++ jako podrobnou analýzu problému. A pokud se ukáže, že se to v tom jazyce nedá rozběhnout (a není to tím, že to neumíš ty) a nedá se posílit HW, tak se může řešit v jaké verzi Fortranu to psát.
On ten Fortran je pro to naučení jednodušší, než C++, C# i Java dohromady. Navíc je Fortran vždy 100% zpětně kompatibilní, takže jednou napsaný program půjde přeložit kdykoli i v budoucnu bez ohledu na verzi.
O Fortranu se jen tolik nemluví, protože Fortran není programovacím jazykem programátorů, ale vědců. A ti potřebují výkon. Například neuronová síť napsaná ve Fortranu vypadá mnohem jednodušeji, než totéž napsané v C++ či Javě a navíc je i rychlejší.
-
Pythton makra _naštěstí_ nemá.
Co si predstavujes pod pojmem makro?
Například jako nějakou alternativu #define v céčku. Máš nějakou vhodnější definici? Co třeba lispové makro? To by bylo zajímavější.
Pokud máš na mysli importy, tak to nejsou makra.
No me zajimalo, jaky konkretne mara mas na mysli, kdyz mluvis o tom ze v necem nastesti nejsou. Protoze me zrovna lispova makra prijdou super (coz je prave panem prymkem zminovany nevyhodnocovani parametru), ale #define zase jako zlo. Takze, aspon u me, nejde zastavat vyhraneny nazor proti "makrum" obecne.
-
Tak vždycky se dá použít cpp a nějakej build script/makefile
Proč používat cpp, když máme m4? :-)
Jenže si stejně ta makra raději nechávám rozbalovat přímo editorem, protože by je nikdo kromě mne nemohl číst. V mém případě makra slouží pouze pro snížení počtu úhozů a počtu chyb - například když si v tu chvíli neuvědomím, zda se v daném jazyce píše else, otherwise nebo default. Na to mám makro, aby to už v editoru napsalo správně.
-
Například jako nějakou alternativu #define v céčku. Máš nějakou vhodnější definici? Co třeba lispové makro? To by bylo zajímavější.
Pokud máš na mysli importy, tak to nejsou makra.
No me zajimalo, jaky konkretne mara mas na mysli, kdyz mluvis o tom ze v necem nastesti nejsou. Protoze me zrovna lispova makra prijdou super (coz je prave panem prymkem zminovany nevyhodnocovani parametru), ale #define zase jako zlo. Takze, aspon u me, nejde zastavat vyhraneny nazor proti "makrum" obecne.
Zkus si ještě jednou přečíst to, co jsem napsal. Makra do Lispu prostě patří, bez nich by Lisp ani nebyl Lispem. Navíc je to naprosto odlišná kategorie, než je třeba #define v céčku.
Pokud by tedy Python nějak rozumně implementoval lispová makra, nebyl bych proti.
-
Ber ten program v Javě nebo v C++ jako podrobnou analýzu problému. A pokud se ukáže, že se to v tom jazyce nedá rozběhnout (a není to tím, že to neumíš ty) a nedá se posílit HW, tak se může řešit v jaké verzi Fortranu to psát.
No, aby se s tou Javou vesel do pameti. Fortran kdysi jel na strojich s 256 MB pameti (kurva, to tehdy bylo ale pameti!) a o vykonu silne zastaraleho PC a pritom se v tom delaly dost narocne veci.
V případě HMM se moc nové paměti nealokuje, většina se počítá "na místě". A když bude 4x více paměti k dispozici než se použije, tak to GC témeř nezpomalí.
-
Výkon se dnes už tolik neřeší. Spíš vhodnost jazyka k danému účelu. Tedy tak, aby se ta aplikace dobře psala, dobře udržovala a schovalo se do ní co nejméně chyb. Šetří se tedy hlavně čas programátora.
Vsak je to vzdycky videt, kdyz vyjdou nove Widle nebo nova verze nejake aplikace. Casu programatora se snad usetri, zato useri asi nevedi, co s casem.
-
Výkon se dnes už tolik neřeší. Spíš vhodnost jazyka k danému účelu. Tedy tak, aby se ta aplikace dobře psala, dobře udržovala a schovalo se do ní co nejméně chyb. Šetří se tedy hlavně čas programátora.
Vsak je to vzdycky videt, kdyz vyjdou nove Widle nebo nova verze nejake aplikace. Casu programatora se snad usetri, zato useri asi nevedi, co s casem.
Záleží na tom, jak to který programátor pojme. Než abych studoval 50 stránkovou dokumentaci k nějakému 10k řádkovému frameworku, raději ten ušetřený čas využiji k tomu, abych si napsal vlastní řešení na 50-100 řádcích. Výsledkem je program, který běží podle mých představ a běží rychle. A ani moc nezáleží na použitém jazyku - zda je to v PHP, Pythonu či v C. Vždy je to rychlejší než cizí framework.
-
Zkus si ještě jednou přečíst to, co jsem napsal. Makra do Lispu prostě patří, bez nich by Lisp ani nebyl Lispem. Navíc je to naprosto odlišná kategorie, než je třeba #define v céčku.
Pokud by tedy Python nějak rozumně implementoval lispová makra, nebyl bych proti.
Prokrýlepána, bavíme se o tom, že pomocí maker se dá zabezpečit mj. nevyhodnocení argumentů fce předem, což se zrovna v matematice perfektně hodí (nejenom na to používání názvů sloupců, ale třeba i pro předávání formulí s neznámými apod.). Co sem pletete cpp nebo dokonce m4?!
-
Fortran je ovsem jazyk znacne staricky, nekdy z doby, kdy mel Zizka jeste obe oci. Jestlipak se od dob sveho vzniku aspon trochu zmodernizoval?
...
Ano dost sa zmodernizoval.
Pocas VS v 90 rokoch minuleho storocia sme na numerike pouzivali F77. Teraz je bezny standard F90, 95 a je to uz o dost modernejsie ako predtym. K dispozicii su free kompilatory gfortran a g95.
Ale má, ve formě _metaclass_
-
Ale má, ve formě _metaclass_
Jestli to měla být reakce na to, že Python nemá makra, tak metaclass není makrosystém. Metaclass je metaclass.
https://en.wikipedia.org/wiki/Metaclass
https://en.wikipedia.org/wiki/Macro_(computer_science)#Syntactic_macros
-
Nevíme na jak dlouhou cestu se chce někdo vydat autem, ale budeme ho zrazovat, že s normálním autem s 50litrovou nádrží by tam taky nemusel dojet, že jiná specializovaná expediční auta si vezou třeba 400 litrů paliva.
A pak se ukáže, že ten člověk třeba chtěl buď dojet autem do Antarktidy, nebo chtěl dojet jenom 30 km do okresního města...
Uklidním tě, nejsi sám kdo si všiml, že to zadání je nekorektní, tak příšerně obecné, že jakákoliv skutečná rada, která by mu pomohla je z oblasti sci-fi(odhadu).
-
Zkus si ještě jednou přečíst to, co jsem napsal. Makra do Lispu prostě patří, bez nich by Lisp ani nebyl Lispem. Navíc je to naprosto odlišná kategorie, než je třeba #define v céčku.
Pokud by tedy Python nějak rozumně implementoval lispová makra, nebyl bych proti.
Prokrýlepána, bavíme se o tom, že pomocí maker se dá zabezpečit mj. nevyhodnocení argumentů fce předem, což se zrovna v matematice perfektně hodí (nejenom na to používání názvů sloupců, ale třeba i pro předávání formulí s neznámými apod.). Co sem pletete cpp nebo dokonce m4?!
Jo, výrazy s volnými proměnnými se hodí. Ještě tu nebyl zmíněn Swift, v něm to jde stylem "Var.x ** Var.y", kde Var je "struct Var : Expression". Pak mi kombinace s matematickými operátory vytvoří AST, jejž lze následně vyhodnotit, derivovat apod.
-
https://xkcd.com/1537/
-
C# pod Linuxom bez problemov. .NET uz je open source.
Matematicke vypocty, velmi zavisi, ze ake..Je skutocne mozne, ze prave pre tie Vase bude najlepsi jazyk Fotran.
Ale inac takmer vsetko by sa malo dat zvladnut v Octave/Matlab alebo R.
-
C# pod Linuxom bez problemov. .NET uz je open source.
Už jsem psal, že C# je příliš univerzální jazyk a pro vědecké výpočty se tedy nehodí. Vždyť ani nemá pole od jedné, ale od nuly. C# je spíš jazykem pro programátory, vědcům víc vyhovuje Fortran. Mimo jiné i proto, že je lépe vybaven pro práci s vektorovými procesory, pro které jsou cykly z C# velkou překážkou.
-
C# pod Linuxom bez problemov. .NET uz je open source.
Matematicke vypocty, velmi zavisi, ze ake..Je skutocne mozne, ze prave pre tie Vase bude najlepsi jazyk Fotran.
Ale inac takmer vsetko by sa malo dat zvladnut v Octave/Matlab alebo R.
Vše se dá zvládnout i v C#, Javě nebo C++. Záleží na tom, co člověk umí a co mu poběží na hardwaru. Špatnou volbou by byl třeba Prolog :) jinak to je fuk. Navíc algoritmy pro HMM jsou složité, takže to chce stejně knihovnu. SAT dtto.
-
C# pod Linuxom bez problemov. .NET uz je open source.
Vždyť ani nemá pole od jedné, ale od nuly.
Má. Například takto vytvoříte pole od 1 do 5: System.Array.CreateInstance(typeof(int), new[] { 5 }, new[] { 1 })
-
Má. Například takto vytvoříte pole od 1 do 5: System.Array.CreateInstance(typeof(int), new[] { 5 }, new[] { 1 })
No fuj. Vytvoření pole s indexy 1..5:
REAL pole(5)
Vytvoření pole s indexy 5..20:
REAL pole(5:20)
Vytvoření třírozměrného komplexního pole o 1000 prvcích:
COMPLEX pole(5, 20, 0:9)
Násobení pole konstantou:
pole = pole * 42
Jak s tímhle chce nějaký C# soupeřit?
-
Má. Například takto vytvoříte pole od 1 do 5: System.Array.CreateInstance(typeof(int), new[] { 5 }, new[] { 1 })
Jak s tímhle chce nějaký C# soupeřit?
Netvrdím, že s tím má C# soupeřit, jen říkám, že tam jde indexovat pole i od 1.
-
Má. Například takto vytvoříte pole od 1 do 5: System.Array.CreateInstance(typeof(int), new[] { 5 }, new[] { 1 })
Jak s tímhle chce nějaký C# soupeřit?
Netvrdím, že s tím má C# soupeřit, jen říkám, že tam jde indexovat pole i od 1.
Ne že bych měl C# nějak zvlášť v oblibě, ale to násobení pole skalárem tam jde taky, jako ostatně v každém jazyce s přetěžováním operátorů.
-
C# pod Linuxom bez problemov. .NET uz je open source.
Už jsem psal, že C# je příliš univerzální jazyk a pro vědecké výpočty se tedy nehodí. Vždyť ani nemá pole od jedné, ale od nuly. C# je spíš jazykem pro programátory, vědcům víc vyhovuje Fortran. Mimo jiné i proto, že je lépe vybaven pro práci s vektorovými procesory, pro které jsou cykly z C# velkou překážkou.
Pišem Vám posledný raz. Ako veľmi často, nemáte pravdu, C# je možné indexovať pole od čoho chcete.. Aj kedy nie, čo áno, tak je triviálne si takú triedu vyrobiť.
Ale očividne je nutné Vám povedať, i keď pochybujem, že to zaberie, lebo s obľubou riešite príspevky, ktoré sa Vás vôbec netýkajú, ale predsa skúsím ozrejmiť, že som odpovedal autorovi otázky a nie Vám. Ako pomerne takmer vždy.. Skúste sa nad sebou zamyslieť alebo si nájdite nejaké hobby, lebo naozaj ste jeden z tých, ktorí tuna nesmierne radi zvrhávajú diskusie..
Neviem, v akej komunite sa pohybujete Vy.. Fotran používajú hlavne fyzici aj keď majú veľký trend prechádzať na C++. Ooops, C++ je univerzálny jazyk. Vedci ohľadom strojového učenia a big data používajú Matlab a R.
-
Fotran používajú hlavne fyzici aj keď majú veľký trend prechádzať na C++. Ooops, C++ je univerzálny jazyk. Vedci ohľadom strojového učenia a big data používajú Matlab a R.
Matlab, R, Octave. Jsou to nástupci Fortranu. Ano, jsou to jazyky pro matematické výpočty a nemám s tím problém.
C++ se však na matematické výpočty nehodí a na tom trvám. C++ je programovacím jazykem programátorů. Pokud se nějaký vědec nechá ukecat programátorem na C++, je to jeho problém.
Fortran je něco mezi. Vědec by měl v prvé řadě sáhnout po jazycích Matlab, R nebo Octave, protože ty mu přinesou požadovaný komfort. Na Fortran ani nemusí přijít řada, případně se v něm dá doprogramovat chybějící knihovna zmíněných jazyků.
Fortran proti C++ ještě jeden příjemný bonus: Programy v něm napsané jsou rychlejší.
-
C# pod Linuxom bez problemov. .NET uz je open source.
Už jsem psal, že C# je příliš univerzální jazyk a pro vědecké výpočty se tedy nehodí. Vždyť ani nemá pole od jedné, ale od nuly. C# je spíš jazykem pro programátory, vědcům víc vyhovuje Fortran. Mimo jiné i proto, že je lépe vybaven pro práci s vektorovými procesory, pro které jsou cykly z C# velkou překážkou.
Pišem Vám posledný raz. Ako veľmi často, nemáte pravdu, C# je možné indexovať pole od čoho chcete.. Aj kedy nie, čo áno, tak je triviálne si takú triedu vyrobiť.
Ale očividne je nutné Vám povedať, i keď pochybujem, že to zaberie, lebo s obľubou riešite príspevky, ktoré sa Vás vôbec netýkajú, ale predsa skúsím ozrejmiť, že som odpovedal autorovi otázky a nie Vám. Ako pomerne takmer vždy.. Skúste sa nad sebou zamyslieť alebo si nájdite nejaké hobby, lebo naozaj ste jeden z tých, ktorí tuna nesmierne radi zvrhávajú diskusie..
Neviem, v akej komunite sa pohybujete Vy.. Fotran používajú hlavne fyzici aj keď majú veľký trend prechádzať na C++. Ooops, C++ je univerzálny jazyk. Vedci ohľadom strojového učenia a big data používajú Matlab a R.
Ještě bych doplnil, že v ekonometrii se také používá hlavně C++, nejspíš kvůli rychlosti. "Quants" na Wall street v drtivé většině v ničem jiném než C++ nepíšou.
-
Fotran používajú hlavne fyzici aj keď majú veľký trend prechádzať na C++. Ooops, C++ je univerzálny jazyk. Vedci ohľadom strojového učenia a big data používajú Matlab a R.
Fortran proti C++ ještě jeden příjemný bonus: Programy v něm napsané jsou rychlejší.
Pro symbolické výpočty to obvykle neplatí.
-
C++ se však na matematické výpočty nehodí a na tom trvám. C++ je programovacím jazykem programátorů. Pokud se nějaký vědec nechá ukecat programátorem na C++, je to jeho problém.
Všechny "matematické jazyky" fungují tak, že je v C, C++ nebo Fortranu napsané knihovny, ve kterých probíhá vlastní výpočet, a nad tím buď je nebo není nějaký ten vysokoúrovňový "matematický" jazyk (R, Python), ve kterém se knihovny lepí dohromady.
Samostatnou kategorií jsou pak výpočty vysoce paralelizované přes nějaké to MPI apod., kde se opět pracuje s C++ nebo spíš samotným C.
Jestli to znamená nebo neznamená, že C/C++ "se nehodí na matematické výpočty", ať si rozhodne každý soudruh sám...
-
Domnívám se, že v jakémkoliv jazyce jde naprogramovat cokoliv. Ale předpokladem je mistrovské zvládnutí daného jazyka a v tomto případě i detailní znalost problematiky HMM a SAT, související algebry a schopnost tohle vtesat do algoritmů. Pokud tohle zvládáš, tak tě upřímně obdivuju.
Spíš bych doporučoval si najít vhodné knihovny nebo celý framework zabývající se problematikou. A s tím už přijde i požadavek na jazyk, který tento framework potřebuje k obsluze.
Příklad: já si teď tak trošku hraju s neuronovými sítěmi, machine learning apod. V této oblasti teď hodně jede framework TORCH. A ten se světem komunikuje v jazyce LUA. Což je skriptovací jazyk nad C. A celé se to opírá o OpenBLAS, což je knihovna pro lineární algebru psaná v C a Fortranu.
Tím chci říct, že není nutné omezit se na jenom jeden jazyk, klidně vem z každého to nejlepší.
PS: ten TORCH+LUA je docela porod, ale kdybych to měl bastlit od píky (tady řekněme násobení matic) sám, tak s tím seknu dávno.
-
Domnívám se, že v jakémkoliv jazyce jde naprogramovat cokoliv. Ale předpokladem je mistrovské zvládnutí daného jazyka a v tomto případě i detailní znalost problematiky HMM a SAT, související algebry a schopnost tohle vtesat do algoritmů. Pokud tohle zvládáš, tak tě upřímně obdivuju.
Spíš bych doporučoval si najít vhodné knihovny nebo celý framework zabývající se problematikou. A s tím už přijde i požadavek na jazyk, který tento framework potřebuje k obsluze.
Příklad: já si teď tak trošku hraju s neuronovými sítěmi, machine learning apod. V této oblasti teď hodně jede framework TORCH. A ten se světem komunikuje v jazyce LUA. Což je skriptovací jazyk nad C. A celé se to opírá o OpenBLAS, což je knihovna pro lineární algebru psaná v C a Fortranu.
Tím chci říct, že není nutné omezit se na jenom jeden jazyk, klidně vem z každého to nejlepší.
PS: ten TORCH+LUA je docela porod, ale kdybych to měl bastlit od píky (tady řekněme násobení matic) sám, tak s tím seknu dávno.
HMM nejsou moc složité (a algebra tam nikde není). SAT je ale oříšek, moderní metody jsou poměrně komplikované a naivní implementace je pomalá. Nicméně nikdy neuškodí zkusit si algoritmus napsat, člověk aspoň problematiku lépe pochopí.
-
A celé se to opírá o OpenBLAS, což je knihovna pro lineární algebru psaná v C a Fortranu. [...] ten TORCH+LUA je docela porod, ale kdybych to měl bastlit od píky (tady řekněme násobení matic) sám, tak s tím seknu dávno.
Jenom poznámka na okraj: OpenBLAS, ATLAS,... se používá snad ve všech těhle frameworcích - i v Rku nebo numpy. Jestli si s tím hraješ víc, zkus taky cuBLAS (CUDA-accelerated BLAS).
-
HMM nejsou moc složité (a algebra tam nikde není).
Je tam lineární algebra.
IMO s tou jednoduchostí to je jako u SATu - triviální problémy vyřešíte učebnicovým algoritmem (konfliktem řízené učení klauzulí), který na těžší problémy nestačí.
-
HMM nejsou moc složité (a algebra tam nikde není).
Je tam lineární algebra.
IMO s tou jednoduchostí to je jako u SATu - triviální problémy vyřešíte učebnicovým algoritmem (konfliktem řízené učení klauzulí), který na těžší problémy nestačí.
Lineární algebru jsem tam teda nikde neviděl. Zato hodně pravděpodobnosti.
Pro HMM ale existuje jen ten "učebnicový" algoritmus, na rozdíl od SAT se urychlit nedá.
-
HMM nejsou moc složité (a algebra tam nikde není).
Je tam lineární algebra.
IMO s tou jednoduchostí to je jako u SATu - triviální problémy vyřešíte učebnicovým algoritmem (konfliktem řízené učení klauzulí), který na těžší problémy nestačí.
Lineární algebru jsem tam teda nikde neviděl. Zato hodně pravděpodobnosti.
Viz třeba Skryté Markovské modely od R. Bartáka, strana 9 (http://ktiml.mff.cuni.cz/~bartak/ui2/lectures/lecture04.pdf#9).
Pro HMM ale existuje jen ten "učebnicový" algoritmus, na rozdíl od SAT se urychlit nedá.
Například učení modelu se dá urychlit (oproti EM algoritmu). Naivní implementace rovněž může mít problémy s velkým množstvím stavů.
-
Pro HMM a SAT zrovna existují knihovny v C, takže jdou volat z v podstatě libovolného jazyka. Z obecného pohledu se hodí pro matematické a obecně symbolické výpočty Swift díky své syntaxi a typovému systému (Apple slíbil vydat otevřený překladač pro Linux). Práci s tenzory pak můžu zapisovat elegantně matematicky, např. násobení matic bude
let A = Tensor(indices: .Contravariant, .Covariant)
let B = Tensor(indices: .Contravariant, .Covariant)
...
let C = A.i.j * B.j.k
Pro manipulaci s vektory lze mít jeden operátor pro násobení dávající skalární, vektorový nebo tenzorový součin podle kontextu:
func *(t1:Vector, t2: Vector) -> Scalar { ... }
func *(t1:Vector, t2: Vector) -> Vector { ... }
func *(t1:Vector, t2: Vector) -> Tensor { ... }
A tak dále. Swift lze přímo míchat s kódem a knihovnami napsanými v C/C++ a využívat OpenCL, OpenMP a podobné knihovny/techniky pro zrychlení výpočtu. Např. ve Stanfordu už Swift pro matematické/symbolické výpočty používají.