Příspěvky

1306

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 26. 09. 2015, 12:34:24 »

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.

1307

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 26. 09. 2015, 10:13:39 »

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ů.

1308

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 25. 09. 2015, 08:23:40 »

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.

1309

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 21. 09. 2015, 12:20:35 »

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.

1310

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 20. 09. 2015, 21:01:21 »

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í.

1311

Vývoj / Re:Přepis programu z Delphi/PASCAL na jinou platofrmu

« kdy: 20. 09. 2015, 14:01:10 »

Tak tohle nikomu nezávidím... Asi bych doporučil .NET nebo Javu, ale takový projekt bude mít tolik detailů, že stručné doporučení napsat nejde.

1312

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 20. 09. 2015, 13:58:56 »

Ž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.

1313

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 20. 09. 2015, 13:55:28 »

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"?

1314

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 20. 09. 2015, 11:32:49 »

Ž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):

Kód: [Vybrat]

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.

1315

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 20. 09. 2015, 11:10:48 »

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.

1316

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 20. 09. 2015, 10:45:24 »

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.

1317

Vývoj / Re:Termy v Prologu

« kdy: 20. 09. 2015, 08:09:31 »

Otázka víceméně ze zvědavosti: proč se v Prologu používají termy (z formální logiky) a ne nějaká jiná struktura.
A druhá: jak se vyhodnocuje pravidlo vyjadřující symetrii nějakého vztahu, např. sourozenec(X,Y):-sourozenec(Y,X)?

1. Protože se dají efektivně unifikovat. Některé logické jazyky používají unifikaci nad stromy nebo nad AVM (to je nejobecnější). A některé mají jen atomy, například Datalog.

2. SLG rezolucí, ta skončí pro každý "nonfloundering" program. Normální Prolog (s SLD rezolucí) se na tom zacyklí. Podle typu úlohy může být lepší použít RETE nebo ASP, to už ale není Prolog.

1318

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 20. 09. 2015, 08:04:31 »

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.

1319

Vývoj / Re:Jazyk pro matematické výpočty

« kdy: 20. 09. 2015, 08:02:17 »

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.

1320

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 18. 09. 2015, 10:37:43 »

To by byl ten případ s (implicitním) přetypováním (operator SquareMatrix()), nicméně ani to mi neumožní napsat v C++ něco jako (m1*m2).trace() (na rozdíl od Swiftu).

Jo, v C++ by bylo třeba něco jako "square(m1*m2).trace()". To není zas tak zlé.

BTW umí nějaký (jiný) jazyk toto?

Kód: [Vybrat]

func *(x:Vector,y:Vector) -> Tensor {...}
func *(x:Vector,y:Vector) -> Double {...}
func *(x:Vector,y:Vector) -> AST {...}

let p:Double = a*b // scalar product 
let p:Tensor = a*b // tensor product
let p:AST = a*b // AST

Docela praktické, hlavně ten AST.

V C# lze dosáhnout v podstatě téhož tak, že násobení vrátí instanci MultiplicationResult a třída MultiplicationResult bude obsahovat implicitní konverzi na double a na Tensor. AST lze získat pomocí Expression - tj. násobení místo parametru typu T bude brát parametr typu Expression<T>.

Ve Scale se použije například (ve Scale bude asi hodně možností, jak dosáhnout téhož) trik analogický tomu s CanBuildFrom - tj. násobení bude mít implicitní parametr BuildResult[T] a vracet typ T. Takto definované násobení pak může kdokoliv (i cizí kód) rozšířit na libovolný návratový typ, případně předefinovat jeho chování pro určité návratové typy. S AST lze ve Scale pracovat pomocí maker.

Benchmark by asi dopadl pro C# v tomto případě špatně.

Nevidím důvod, proč by to implementace C# nemohla zoptimalizovat stejně jako Swift. Nevím, jestli to RyuJIT od MS dokáže, nicméně MSIL lze přeložit i do LLVM (Mono, SharpLang, LLILC - zatím značně nekompletní) nebo do C (C# Native).

To nevím, jak C# optimalizuje. Vtip je v tom, že Swift tady nic optimalizovat nemusí, jedna metoda se vybere v době překladu. Pokud instanci MultiplicationResult v C# použiju víckrát, tak tam moc prostoru k optimalizaci není.