Programovací jazyk pro fyziky? (diskuse)

[masomlejn]

Sice nejsem fyzik, nybrz chemik ale doporucuju ti FORTRAN (subjektivni nazor!). Existuje v nem spousta knihoven na reseni ODE, PDE atd, ktere jsou podle me to nejlepsi co se na "trhu" nachazi. Ja sem taky samouk s totalni absenci matematickeho ci programatorskeho vzdelani a muzu rict, ze FORTRAN se mi jevi jako nejintuitivnejsi. Kombinace FORTRAN + C je mozna, kazdy kus kodu zkompilujes do objektu ((gcc || g77 || ifort | ...) -g) a pak je slinkujes dohromady. Do Monte Carlo jsem moc nefusoval, ale muj skolitel ma na ni udelanou sadu programu v C. Tu ti ale nemuzu bohuzel bez jeho svoleni poskytnout. Jinak jsem delal Molecular Dynamics a pouzival jsem na to program DL_POLY, ktery je psan ve FORTRANu:

 
@ARTICLE{96SMI/FOR,
  author = {Smith, W., and Forester, T.R.},
  title = {DL\_ POLY\_ 2.0: A general-purpose parallel molecular dynamics simulation
	package},
  journal = {J.Mol.Graphics},
  year = {1996},
  volume = {14},
  pages = {136--141},
  availability = {reprint av. SIM },
  keywords = {SIM DLPOLY},
  owner = {milan}

[nooneanymore]

Máš nějaký dobrý zdroj informací o programování ve FORTRANU? Taky se mi Fortran zdá intuitivnější než C, ale učebnic o C, se mi zdá, je o hodně víc. Navíc dneska kdekdo přechází k C, aniž vím proč... Proč?

[pasmen]

Prechod od Fortranu k C ma jednoduchy duvod. Fotran byl navrzen jako jazyk pro matematicke vypocty, ktere byli velice slozite a tenkrat pocitace nemeli takovy vykon jako dneska. C kompilery nebyli na vypocty optimalizovany, tudiz uspora casu byla nesporna. Dneska uz je situace naprosto odlisna, v obou aspektech.

[nooneanymore]

Takže kvůli tomu, že dneska se rychlost obou jazyků vyrovnává, se přechází na C? Asi ne. Musí být nějaký důvod, zřejmě uživatelský, na který nemůžu přijít.

[Käyttäjä 11133]

V okolí je více lidí, kteří rozumí Cčku + více vyhovující vývojové prostředí? Jen tipuju.

[pasmen]

C byl od pocatku mnohem intuitivnejsi, benevolentnejsi a mocnejsi jazyk. Za cenu jiste ztraty vykonu. Protoze se to dnes smazava, dava se prednost jemu. Prece jen je o uroven vyse.

[peter_h]

Nebude to aj tym, ze sa tam zaviedol typ pre komplexne cisla? (aj ked som to v zivote nepouzil, som 90% presvedceny ze tam take nieco je)
Dalsi dovod moze byt, ze vacsina kniznic pre rozne akceleratory vypoctov sa distribuuje vo formate vhodnom pre C (lib subory). Ale s tym fortranom to podla mna nie je zle, ma mnozstvo kniznic a aktualne kompilatory (napr. intel).

[Käyttäjä 11133]

Fortran taky umí komplexní čísla.

[Miloslav Ponkrác]

Ty dneska umí už kdeco. Umí je C++, umí je Python, umí je Lisp, umí je Fortran... Akorát Java je přímo neumí.

[Michal Vyskočil]

Navíc dneska kdekdo přechází k C, aniž vím proč... Proč?

Protože ani C není vhodné pro Pojídače koláčů (programování v C mohou opravdoví programátoři ocenit: žádná kontrola typu, jména mohou mít 7 (10?, 8?) znaků a dodaný užitek datového typu ukazatel není k zahození - podobně jako mít na jednom místě nejlepší části jazyka FORTRAN a assembleru (a to nemluvíme o define))

Zkus se podívat na SciPy, Python sice není Fortran, ale ta knihovna je stejně napsaná v C. Navíc je možné přes modul ctypes kombinovat kód v Pythonu a C, pyfortran umožňuje propojení numpy s fortranem a nějaký f2py pro generování rozhraní z Fortranu do Pythonu ...

[masomlejn]

V rychlosti jsem ti sem nahazel svoje bookmarky
Fortran 90 for the Fortran 77 Programmer
UWA Theoretical Chemistry - Intel on Debian
VMD - Visual Molecular Dynamics
RasMol V2.7.2.1.1 README
Skriptovani v BASH
Catalog of Free Compilers and Interpreteers: introduction
compilers.net
FORTRAN 77
Koders
C++ Reference Project
C++ Language and Library
gnuplot tips (not so Frequently Asked Questions)
National Supercomputer Centre in Sweden
Fortran 90/95 texts and links
Fortran Programmer's Guide: Index
usefull-scripts-perl
Takze to je takova smeska vseho moznyho. Doporucuju hned ten prvni.

[nooneanymore]

Děkuji, některé stránky znám. Spíš jsem měl na mysli něco takového. V Čechách jsem nic podobného nenašel.

[masomlejn]

hmm... wunderbar. Vetsinou takovouto literaturu davam jako darek pod stromecek segre nebo mame, ty mi to samozrejme omlatej o hlavu a pak mi ji daj, ze prej si tu knizku uziju vic nez ony. Nakonec jsou rady jako ze neco dostaly. Jinak sem se mrknul do databaze v nasi knihovne a z tech novejsich tam mame jen: Akin, Ed; Object-oriented programming via Fortran 90/95. Online tam zadna neni .

[Fuky]

Odpověďi na tyto otázky by Ti měly pomoci:

• Jak dlouho se Fortran používá pro to na co byl vymyšlen?
• Kolik je v něm odladěných, časem prověřených algoritmů, které Ti ušetří spoustu času, protože nebudeš muset znovu vymýšlet kolo?
• Umožňuje Ti Fortran relativně pohodlně specifikovat složité matematické problémy? Má v tomto směru vůbec nějakou konkurenci?
• Uvědomuješ si co mají za následek desítky let práce na Fortranovských překladačích?
• Myslíš, že budeš počítat pouze na platformě PC?
• Proč většina lidí používá ve vědě Fortran, dokonce i ti mladí nezatížení předsudky?
• Zamysli se nad tím kdy Fortran vzniknul a proč se stále dodnes neustále zlepšuje a vyvíjí?

Soukromý názor:

• Výpočty - Fortran
• Nízkoúrovňové systémové programování - C
• GUI - C nebo Python, případně jejich kombinace
• Webové služby - Java

Podle mě je dobré být otevřený novým myšlenkám a postupům, ale nepodlehnout módě. Dát na selský rozum. Ověřit si vše v praxi. Dělat věci nástrojem, který je na danou věc nejšikovnější => naučit se skupinu jazyků pomocí, kterých dokážeš vyřešit snadno a efektivně všechny problémy, které se Ti dostanou pod ruku. Navíc zjistíš-li, že existuje mnohem lepší nástroj, tak se ho zkrátka naučíš používat a vyměníš ho za starý. Ovšem je otázka jestli Ti umožní navázat na předchozí práci a nebude Tě nutit příliš mnoho věcí psát znovu, pak starý nástroj stejně budeš muset dále používat na předchozí projekty.

Jinak není žádný problém ve spolupráci C, Fortran, Python. Pro Python můžeš psát rozšiřující moduly v C i Fortranu. Knihovny v C můžeš využívat ve Fortranu a naopak.

[nooneanymore]

Souhlasím. Ale proč i ve vědě lidé přecházejí k C? V čem je lepší než Fortran?

[Miloslav Ponkrác]

Ale proč i ve vědě lidé přecházejí k C

Tipnul bych si kvůli větší podpoře a kvůli tomu, že jazyk C++ je celkově lepší, než Fortran. Sám jsem ve Fortranu na škole dost programoval, a vždy dám raději přednost C/C++.

Fortran je prostě stařeček, ve kterém je toho ale plno naprogramováno, což ho drží. Ale oproti luxusu třeba C++ se (subjektivní názor) prostě nechytá.

Stejně tak je luxusním jazykem třeba Python, ale je velmi pomalý oproti C++, případně Fortranu.

[nooneanymore]

A v čem je Fortran stařeček?

[Miloslav Ponkrác]

Fortran přeci jenom vzniknul už v 50-tých letech jako první vyšší programovací jazyk na světě a je to na něm dost znát. Má už kolem 60 let!!! To snad stačí na to, abych ho prohlásil za stařečka, nebo ne?

Sice se Fortran stále vyvíjí, ale já osobně považuji C++ za daleko luxusnější jazyk, ve kterém se píše daleko snadněji a rychleji. Přeci jenom Fortran byl první pokus, ve kterém se zcela všechno nepovedlo jak má (subjektivní názor).

Pro vědeckotechnické výpočty je podle mě jediná výhoda Fortranu (i když značná) obrovské knihovny v něm napsané. Pro tyhle případy ale existuje možnost míchání C/C++ a Fortranu.

Já osobně prostě pro sebe nevidím důvod, proč pokračovat ve Fortranu, a proč to nepřevést na jiný schopnější kompilovaný jazyk, třeba to C++. Nehledě vůbec na to, že třeba C++ má od svého vzniku vlastnosti, které dostal Fortran do vínku v normě teprve před několika lety. Jednoduše se vůbec divím, jak se vůbec může někdo divit, že se od Fortranu lidé odklánějí.

[nooneanymore]

A co říkáte na tohle ? Nečetl jsem to celé, ale poslední řádky jsou zajímavé.

[Miloslav Ponkrác]

Jestli si všímáte, tak Vás nenápadně směřuji ne na C, ale na C++. Protože C++ je asi tak o několik řádů schopnější, než C. Protože ten Váš materiál srovnání Fortranu versus C by v případě Fortran versus C++ dopadl tak, že všechny body by vyhrálo C++ a prohrál Fortran, v některých případech by to byla maximálně remíza.

[Michal Vyskočil]

Má už kolem 60 let!!! To snad stačí na to, abych ho prohlásil za stařečka, nebo ne?

A Lispaři tě umlátí čepicemi

na jiný schopnější kompilovaný jazyk, třeba to C++

Čím to, že jsem četl komplikovaný? C++ a šablony, toť syntaktický humus, ale jinak vcelku užitečná věc (včetně takových věcí jako parciální specializace a podobně). Pokud chce člověk napsat kód, kterému nebude 90% programátorů rozumět, už nemusí používat Lisp (anebo vlastně může)

[Miloslav Ponkrác]

Lisp přeci jen vzniknul o chloupek později, ale jinak je to taky děda.

C++ je komplikovaný, pokud ho chcete umět na 100%, to je bezesporu. A šablony to je bezvadný způsob jak něco zamotat - ideální jsou alespoň 3 parametry. Musí se používat rozumně a hlavně dobře okomentovat a odladit. Ale napsat kód, kterému se nedá rozumnět jde všude, stačí vhodně zarovnávat příkazy.

[Michal Vyskočil]

C případě Pythonu používat labmda, map a reduce.

Mě se myšlenka šablon líbí, je to tak trochu ekvivalent maker v Lispu (taky umožňuje udělat mnoho věcí v době překladu), ale ta jejich syntaxe je hnusná a viditelně do jazyka dolepená.

[finn]

Matlab (GNU/Octave)

[buff]

+1 Taky se přikláním k Matlabu. S případným voláním céčkového nebo fortranového kódu, na které má interface. Fyzik však nejsem.

[nooneanymore]

Octave znám a pohybuje se úplně v jiných rovinách než uvažuju. Matlab nebo Octave se dá použít spíš jako nástřel nebo jen k vizualizaci. Na náročnější věci ani Matlab ani Octave nejsou.

[finn]

Matlab disponuje překladačem, takže ani pokud jde o rychlost, nemusí na tom být špatně.

[nooneanymore]

Zaujalo mě toto , hlavně ten Lisp. Takže jsem si myslel, že by se pro interface použít dal. Pravda je, že programů psaných v lispu moc není. Myslím, že jsem někde četl že AutoCAD? Pokud tomu tak je, je to pro tento jazyk dobrá vizitka.

[Radek Šlesinger]

AutoCAD, pokud vím, používá dialekt LISPu (AutoLISP) jako makrojazyk, ale psaný v něm předpokládám není.

[Miloslav Ponkrác]

V LISPu bývají makrovány věci staršího data vzniku - Emacs, AutoCAD, atd.. Dnes už se v tom věci moc nemakrují.

LISP podle mě překročil hranici až zbytečné minimalističnosti na to, aby byl užitečný. Podle mě jazyk musí mít určitou minimální množinu prvků, aby byl nějak víc rozšířen a prakticky používán. Nejnižší hranice podle mě je Smalltalk.

[Tom.š Ze.le.in]

Nedá mi to, ač jsme OT.

Co si představujete pod pojmem LISP? Současné Lispy (Scheme, Common Lisp) toho mají v sobě docela dost a CL bych nenazval minimalistickým ani náhodou (co vám v CL chybí? Hash tabulky/vektory/vícerozměrná pole umí, reálná čísla umí, cykly umí, OOP umí možná lépe než kdokoliv jiný, jediné co asi opravdu ve standardu chybí je práce se sítí, ale to řeší každá implementace, případně knihovny).

[Miloslav Ponkrác]

Myslel jsem minimalističnost syntaxe. LISP podle mě už překročil hranici toho, kdy je většina lidí ochotna akceptovat tak malý počet prvků jazyka - a pro většinu lidí je takový jazyk špatně čitelný (subjektivní názor, tak to vnímám já).

Jinak současné LISPy toho v sobě mají docela dost, ale jejich rozšíření, které šlo spíše dolů, také o něčem svědčí.

[rADOn]

ja bych to videl takhle:
bud neco funkcionalniho - lisp, haskel, smalltalk nebo neco v tom stylu.
nebo neco ciste skriptovanyho - python, ruby, perl, tcl... jsou podstatne pomalejsi ale zase se relativne snadno navazuji na C. takze klasickej pristup je rychle naprototypovat v pythonu a pokud je to pomaly vyprofilovat narocny mista a ty pak prepsat do C/C++. cecko je uz zalezitost pro profi programatory (bez pointeru to ani nezkousej ale zase neni nic rychlejsiho
javu bych vypustil, to je job na plnej uvazek, hlavne pro lidi kteri si radi hraji na 'enterprise' a vymysli znovu kolo. na nektery veci je vyborna ale obecne cokoliv v jave bude v pythonu kratsi a jednodussi a s trochou vlozenyho cecka i podstatne rychlejsi. napr. prace s retezci je v jave opruz gigantickych rozmeru, webserver v jave je rychlejsi nez holej python/perl ale podstatne pomalejsi nez apache+mod_python/mod_fcgi
nevim jak treba ruby ale python se AFAIK u vedecky komunity tesi jistymu zajmu a existuji i specialni moduly pro praci s cisly neomezene presnosti, velkymi vektory a podobne legrace.

[Miloslav Ponkrác]

python je dobrá věc, ale je potřeba říci, že python hodlá udělat řez, kdy končí s kompatibilitou, a to akcí python 3000. takže možná je otázka, jak s pythonem dále

[miro]

Abyste mi rozuměli: neplánuju psát pouze výpočetní programy, které spustím příkazem v konzoli a pak data zpracuju a zvizualizuju matlabem nebo gnuplotem. Budu chtít, aby se můj program skládal jak z uživatelského rozhraní, tak z výpočetní části. Abych v laboratoři viděl hned výsledky.

Osobne som prisiel na to, ze pouzivat jedneho molocha na riesenie vsetkych problemov nie je celkom ono. Sam som sa priklonil k nazoru rozdelit jednotlive ulohy na samostatne casti a na kazdu samostatne hladat najlepsie riesenie.

Ovladam C/C++, Javu, dalej Pascal a Fortran (posledne dva len na urovni skolskej vyuky...), samozrejme nejake male skriptikovanie. Ked som si vyberal v com budem pisat, hned som zavrhol pascal a fortran. V pascale nepise skoro nikto a hoci vo fortrane sa pise stale aj u nas velmi vela (KNM na MFF), mne uz jednoducho podobny jazyk nesedi. Okrem toho viem spravit most na volanie fortranovskej kniznice v cecku a cecka z javy, takze mozem pouzit fortranovsku kniznicu v cecku aj v jave.
Nakoniec som zvazoval podla nasl. veci:

• rychlost vyvoja
• podpora a dostupnost vyvojovych nastrojov
• rychlost kodu

Spravil som si nejake benchmarky porovnavajuce rychlost javy a cecka a zistil som ze doby ked bola java radovo pomalsia su davno prec... Z vyvojovych nastrojov su na tom oba jazyky dobre, osobne pouzivam eclipse aj na jeden aj na druhy. Takze zvitazila rychlost vyvoja, osobne v jave pisem rychlejsie (mozno preto, ze neponuka taku bohatost :)

Inak, javu pouzivam prave na konzolove aplikacie (vramci numeriky), na vyzualizacie pouzivam externe programy (nemam ambicie preprogramovat gnuplot...)
Takze momentalne som na tom nasl:
hlavna kostra mojej prace: java
z javy volam jednu ceckovu kniznicu (cez JNI) a okrem toho z nej spustam dalsi program
vypocitane vysledky dalej vizualizujem pomocou gnuplotu a mencodera

Az v buducnosti pride nieco lepsie, tak to pomerne lahko mozem zacat pouzivat. Snazil som sa svoju cast kodu pisat modularne...

[nooneanymore]

Nechtěl jsem, aby to vyznělo tak, že chci programovat nějakého molocha. Ale někdy je integrace různých nástrojů do jednoho celku nutná. Samozřejmě bych mohl napsat skript v bashi, ale přece jenom možnosti bashe jsou omezené. Když jsem psal ten citovaný odstavec, měl jsem na mysli jedno měření, co se pořád opakuje. To se pak něco psát vyplatí, ne?

[miro]

Myslel som, ze uvazujes o napisani komplexnejsieho programu, ktory jednak bude merat data, jednak ich nejako zlozitejsie spracovavat a nakoniec aj vyzualizovat. Ten program nemusi byt nutne skript v bashi a napriek tomu moze volat cudzie veci, to som mal primarne svojim prispevkom na mysli. Ak chces viacmenej vsetko pisat sam, tak (hlavne z dovodu GUI ale aj ineho) by som odporucil uz len niektory z novsich jazykov. Inak, ono az tak nezavisi na tom, ci budes pisat program pre potreby fyziky alebo niecoho ineho... Ide o to, aky velky asi ten program bude, co asi by mal zvladat (napr. mozes chciet posielat merania po sieti dalej na spracovanie...) a tak podobne. Problemy typu sposob ukladania poli a praca s velkymi cislami su podla mna v tomto pripade druhorade (jedine ze by tam hlavnou otazkou bol vykon) Osobne preferujem na vacsie veci javu. Je od C/C++ jednoduchsia (moj nazor - pracujem dodnes v oboch jazykoch), ma kopec funkcnosti v zakladnej distribucii, da sa v tom pisat aj GUI.
A nemusis riesit problemy s pointrami, upratovanim pamate a podobnymi nepodstatnostami :)

[Miloslav Ponkrác]

Já bych na matematiku právě Javu vůbec nedoporučil. Už jen proto, že nemá přetěžování operátorů, ani dostatečný počet základních matematických typů s vestavěnými operátory. Ono počítat třeba s komplexními čísly, nebo maticemi stylem:

f = a.add(b).plus(c).minus(d).mul(e);

není moc vhodné. Doporučuji vybrat si jazyk, který má přetěžování operátorů, když už si člověk může vybrat. Speciálně pro matematiku a pro výpočty to velmi potěší.

[miro]

Tiez mi to spociatku ako matematikovi chybalo, ale zvykol som si. A popritom stale dufam, ze sa java pretazovania operatorov este docka.

[Miloslav Ponkrác]

Zkuste se pravověrnému javistovi zmínit o tom, že Java by měla mít přetěžování operátorů a vydědí Vás.

To už bych raději Python, nebo Ruby, nebo C#, kde přetěžování operátorů funguje. Případně u kompilátorů skoro cokoli - C++, Ada, prostě cokoli s přetěžováním operátorů.

[miro]

Mne sa na jave paci jednoduchost, ktora mi v C++ chyba. Ale prave vdaka tej jednoduchosti v jave chyba urcita funkcnost ktora je v C++. Postupne sa ale do jazyka dostavaju veci, ktore v nom povodne neboli (napr. verzia 1.5 bola dost obohatena) a z jednoduchosti prilis nestraca.

Matematicke kniznice su momentalne pisane bud v C++ alebo v jave, takze tym sa viacmenej C# vylucuje. Python alebo Ruby su pre mnoho ludi (vratane mna) stale exoticke jazyky, asi sme prilis lenivy ucit sa furt nieco ine :|

[Miloslav Ponkrác]

Java není jednoduchá, Java je očesaná a to je rozdíl. Takový Python je skutečně jednoduchý, a přitom není očesaný, abych uvedl subjektivní příklad.

Java 1.5 musela být obohacená, protože v konkurenci C# už Java nedokázala zdůvodnit svojí očesanost.

C++ a C# se snesou velice dobře - celá .NET technologie přímo masívně podporuje mixování mnoha jazyků, není problém to míchat

ale vše co píšu, píšu ze svého hlediska, a pro Vás mohou být priority samozřejmě jinak

[vch]

Ovšem je třeba mít na paměti, že přetěžování operátorů v základní podobě (tedy bez expression templates) znamená automaticky vytváření dočasných proměnných, což může zruinovat rychlost programu, hlavně pokud se jedná o vektory nebo pole a pokud se to provádí v nějaké vnitřní výpočetní smyčce.

Ve výše uvedené řádce kódu bych to i v C++ řešil vytvořením několika metod f.scaleAdd( double, Vector ), f.scaleAdd( double, Vector, double, Vector ), atd. a v nich používal klasické Cčkovské cykly.

Jinak co se týče otázky, v jakém jazyku programovat výpočty, rozhodně bych volil mezi C a C++. A pro C bych se rozhodl navíc jen tehdy, pokud bych s ním už měl zkušenost. Fortran také není špatný, ale na klasické verzi 77 mi vadí ta těžkopádná syntaxe, nevím, jak moc se změnila v novějších verzích.

[nooneanymore]

Čistě ze zájmu teď čtu něco o Emacs Lispu (on sám ten Emacs je zajímavý), na stole mám knížku "Od C k C++", tak se uvidí. Ve Fortranu je asi dobré umět se aspoň trochu v něm orientovat, výpočty budou v C a interface zatím nevím, podle toho, jak zvládnu C++. Předtím musím zvládnout pointery, abych je rval kam jen to jde a třebas je používal jako pole, či co se stím dá dělat. Jeto plodná diskuze, všem děkuju. Akorát jsem se zatím nedověděl, jak je to s funkcionálními jazyky ve fyzice.

[Miloslav Ponkrác]

Snad jen taková věc: Od té doby, co dělám v C++ se intenzita používání pointerů prudce snižuje na hodnotu blízkou nule.

Jinak co Vám brání použít funkcionální jazyk? Je jen potřeba říci, že pokud je rychlost vaší preferencí, tak to nebude dobrá volba.

Podle mě se hlavně pořádně naučte něco a to něco pak používejte.

[Hynek (Pichi) Vychodil]

Jinak co Vám brání použít funkcionální jazyk? Je jen potřeba říci, že pokud je rychlost vaší preferencí, tak to nebude dobrá volba.

Ale kuš už rozumbrado. Takovejch nesmyslů co už jsi tu vyplodil se jen tak nevidí. Jdi už s tím svým C++ tam kam slunce nesvítí. Třeba takový GHC Haskelu dýchá C++ dost zdárně na záda a třeba v jednoduchosti paralelizace se funkcionálním jazykům imperativní geronti nedotádnou ani po kotníky a nedejbože aby to bylo objektové C++.

[Miloslav Ponkrác]

Děkuji za milá a vlídná slova, ty brouku

[Miloslav Ponkrác]

Jenom jsem čekal, kdy se objeví někdo s Haskellem. Jasně, že kompilátor bude dýchat jinému kompilátoru na záda. Obecně jsou ale funkcionální jazyky pomalejší, respektive každý běžný imperativní jazyk bude vždy aspoň o krapítek rychlejší, než jakýkoli funkcionální jazyk, včetně GHC Haskellu (poznámka pro Vás: píše se se dvěma l).

Jinak já proti funkcionálním jazykům nic nemám, jen jsem napsal, že jsou pomalejší, a ony obecně jsou. Problém je, že sám autor nenapsal, jaké jsou jeho podmínky pro jazyk, pro který dělá výběrové řízení.

Pokud jde o rychlost, nenajdete lepší jazyk, než C++. Přestože za jistých podmínek mu občas bude něco jiného dýchat na záda.

Pokud rychlost není až tak klíčová, pak je to celkem jedno - výběr je obrovský.

[klingac]

Tak pridam teda aj svoj skromny nazor. Boli casy kedy bol Fortran pre fyzikov to najlepsie - proste bol optimalizovany na matiku a bola k tomu spusta kniznic. Ale bezny experimentator pozaduje od pocitaca nielen vypocty ale sem tam aj nejake to ovladanie experimentu a pod. Na to je viac vhodne C. Vznikol problem - kniznice v C aj vo Fortrane. Jeho riesenim sa stali kniznice cernlib :) Neviem jak (sam tomu celkom nerozumiem,nie som informatik) sa vdaka nim nalinkuju kniznice z fortranu a tym padom staci (za pouzitia vhodneho kompilatora) bastlit potrebny programek v C/C++. Odvtedy akosi nie je az tak nutne pisat vsetko vo fortrane ;o) Medzitym doba pokrocila, C si ziskalo celkom slusnu zakladnu programatorov a z Fortranu sa stal de facto mrtvy jazyk( sice som zacul ze matici a pod ho este stale vyuzivaju ). V C/C++ vzniklo kopu kniznic, vdaka nim mozete ovladat experiment, spracovat data a nakoniec ich aj zobrazit. Na zapeklite problemy matematickeho charakteru staci vyuzit cernlib(mimochodom v niektorych distrach ako Scietific Linux ich najdete defaultne,inak su repozitaroch Debianu). To by mozna aj bola odpoved na otazku preco prechod k C. V sucasnosti vsade ciha prave C-ma silnu a pocetnu komunitu a skvele hotove a odladene nastroje pre fyzikov. Z vlastnej skusenosti na programovanie pre fyzika by som preto doporucil C/C++ a vyuzivanie hraciciek ako je trebars ROOT. Vdaka ROOTu sa da relativne rychlo nabastlit kod, ktory nasimuluje, spracuje aj zobrazi data a navyse to bude aj slusne rychle (nenadarmo ho vyuzivaju v CERNe). Dokumentacia je perfektne spracovanana na nete a je tam kopa programkov uz hotovych (rozne tutorialy). Navyse kto sa s nim nauci pracovat ziska dost velku vyhodu nad konkurenciou, ktorej je pomerne malo (aspon zatial) - o tom ma presvedcil napr. aj posledny astronomicky kongres v Prahe.

[miro]

+1

[Miloslav Ponkrác]

Konečně to někdo napsal. Tohle je super příspěvek. V C/C++ jsou prostředky nejen na výpočty, ale i na ovládání zařízení a na cokoli jiného, což se při matematickofyzikálních experimentech velice časem může hodit. Jiné jazyky stejně často pomoc Céčka potřebují tak jako tak.

[nooneanymore]

O ROOTu jsem taky už slyšel, a to v souvislosti právě s jadernou fyzikou. Studuju na Katedře fyziky povrchů a plazmatu a zatím jsem tam na něj nenarazil, ale nebude vadit, když nějaké nové zvyky tam vnesu, že?

[nooneanymore]

Doplnil jsem původní text o požadavky na jazyky. Zatím se zdá být nejlepší kombinace C a C++, která je obecně používána v oboru nejčastěji. Ale další diskuze možná ukážou nové obzory.

[Miloslav Ponkrác]

Pokud tam máte na výpočetní jazyk rychlost, pak neseženete nic lepšího, než imperativní kompilovatelný jazyk. C++, Ada, cokoliv. Doporučuji C++, protože se snese téměř s jakýmkoli jiným jazykem, je to jazyk dělaný na max. rychlost už od počátku a jeho možnosti jsou obrovské. Velká komunita uživatelů a podpora v kompilátorech je samozřejmostí. Vhodnost konstrukcí jazyka C++ k matematice a vyjádření abstraktních výpočtů je daná. Nutno říci, že C++ není nejjednodušší jazyk na učení.

Pro ten druhý jazyk bych doporučil hlavně něco, co má snadné GUI - doporučil bych třeba Python. Python byl původně dělán pro matematiky a i pro něj jsou k dispozici slušné matematické knihovny. Python se naučíte velmi velmi rychle, je až ďábelsky snadný a přitom ohromně schopný jazyk.

Co bych určitě nedoporučil? Javu - Java jde ve všem příliš vlastní cestou, je to příliš očesaný jazyk, aby byl pro matematiku užitečný.

[ChinChuLin]

Pokud tam máte na výpočetní jazyk rychlost, pak neseženete nic lepšího, než imperativní kompilovatelný jazyk. C++, Ada, cokoliv. Doporučuji C++, protože se snese téměř s jakýmkoli jiným jazykem, je to jazyk dělaný na max. rychlost už od počátku a jeho možnosti jsou obrovské. Velká komunita uživatelů a podpora v kompilátorech je samozřejmostí. Vhodnost konstrukcí jazyka C++ k matematice a vyjádření abstraktních výpočtů je daná. Nutno říci, že C++ není nejjednodušší jazyk na učení.

Nesezene nic lepsiho nez Fortran - v C musi matematicke funkcne nastavovat errno, ma prisnejsi pravidla pro poradi provadeni operaci a tim padem mensi prostor pro optimalizace atp.

Pro ten druhý jazyk bych doporučil hlavně něco, co má snadné GUI - doporučil bych třeba Python. Python byl původně dělán pro matematiky a i pro něj jsou k dispozici slušné matematické knihovny. Python se naučíte velmi velmi rychle, je až ďábelsky snadný a přitom ohromně schopný jazyk.

Co bych určitě nedoporučil? Javu - Java jde ve všem příliš vlastní cestou, je to příliš očesaný jazyk, aby byl pro matematiku užitečný.

Javu(+Eclipse) bych urcite doporucil - neni to jazyk ocesany, ale genialnim zpusobem oprosteny od veci na kterych si zavili zastanci OOP radi honi saska, ktere ale snadno vedou na scesti. Jednoduchost Javy naopak vede k cistemu a explicitnimu kodu, a umoznuje existenci silneho IDE, ktere najde vsechny syntakticke (a diky vynucene cistote kodu obvykle i semanticke) chyby a nabidne UPLNY seznam moznych reseni, a to v podstate instantne, kdezto kompilatoru C++ muze u slozitejsich konstrukci trvat odhaleni chyby desitky sekund, a prvni chyba navic obvykle "rozhodi" zbytek kodu, ktery pak hlasi falesne chyby. V Pythonu pak toto nejde vubec, nebot syntakticka spravnost muze zaviset na podminkach za behu, jako treba na vstupnich datech.

[Miloslav Ponkrác]

Ohledně Javy - bavím se o funkčnosti Javy, ne o tom, že si někdo honí šaška na lživém výroku, že je Java OOP a že je tzv. "čistá". Jak říkám, Java nemá přetěžování operátorů, což bych pro matematické aplikace považoval za nutnou podmínku. Jinak ona ta očesanost Javy, kterou tu chválíte, a díky které může existovat silné IDE si vybere svojí daň jinak a jinde - neustále nutností opisovat algoritmy jinak, ohýbat je směrem k Javě. Vždyť i to silné IDE "generuje" obvykle běžné případy Javovských vzorů kódu, jinak by Java byla téměř nepoužitelná pro rychlé programování. Takže znovu, Javu bych na matematiku rozhodně nepodporučil, i když nepopírám, že jde o můj subjektivní názor. Řekl bych skoro, že Java je na cokoli vhodnější, jen na tu matematiku ne.

[zde]

Já přetěžování operátorů rád nemám, je to nejednoznačné.

a = [1, 2]
b = [3, 4]
c = a + b

Co má být v c? [1, 2, 3, 4]? [4, 6]? Něco jiného? Co násobení? Kartézský součin? Vektorový součin? Skalární součin? Když to budete chtít dělat pořádně a jednoznačně, velice rychle zjistíte že nemáte dost přetížitelných operátorů...

[Miloslav Ponkrác]

Proboha tohle je věcí symboliky. Když dám metodu add() co má být v c? [1, 2, 3, 4]? [4, 6]? Něco jiného? Co násobení? Kartézský součin? Vektorový součin? Skalární součin? Vidíte, že stejný problém vznikl, aniž bych použil operátory. Že to vůbec není problém operátorů.

Operátorů je relativně dostatek na to co je obvykle potřeba. A oni se používají nejen pro matematické výpočty.

[Fuky]

Rozjela se tady celkem plodná diskuze, ale podle mě se jí účastní příliš málo lidí. Hodně lidí, kteří mají podle mě co říct najdeš na linux@linux.cz (Meta-FAQ konference), takže si myslím, že by nebylo špatné tam poslat stejný dotaz i s linkem na zdejší diskuzi

[zde]

http://scipy.org/

[Tom.š Ze.le.in]

Zrovna na MFF byl kdysi vyvinut a používán jazyk/prostředí Famulus, který byl pro to co potřebujete v zásadě určen. Jeho současný stav mi je ale neznámý, a Google moc nepomohl. Ale poptal bych se, byl docela jednoduchý a pro malé věci dobrý.

[Käyttäjä 11133]

Pár informací o Famulu.

[nooneanymore]

Famulus znám, ale myslím, že na fakultě je málokdo, kdo by to s jeho využíváním mimo praktika myslel vážně.