Vlákno názorů k článku Programovací jazyk Julia: další stříbrná kulka v IT? od K> - Dle clanku Julia ma byt lepsi jazyk nez...
-
K> (neregistrovaný)
Dle clanku Julia ma byt lepsi jazyk nez Matlab/Octave/Numpy/Scipy/R, cokoliv. Jakozto clovek zivici se numerickymi vypocty profesionalne mam spis pocit, ze neni potreba novy jazyk, ale ucelenejsi soustava knihoven. Ostatni programy jsou dobre prave proto, ze umi spocitat ten statisticky test, onen typ prolozeni, generovat nahodna cisla podle tohoto rozdeleni atd. Jsou dobre diky svym rozsahlym knihovnam. Jestli smycku musim napsat jako for...end nebo for{...} ci jakkoliv jinak, tak to je mi celkem ukradene. A jestli se neco pocita 0.01 nebo 0.02 vteriny taky neni pro mne az tak dulezite, protoze ja stejne nedokazu napsat tak optimalizovany program, abych to vyuzil. Teda je pravda ze pri nekterych simulacich uz to citim, ale jestli se neco pocita 2 dny, a s Julii by se to pocitalo o 2 hodiny kratsi dobu, tak to neni duvod.
Naopak me zarazi, ze pokud autori Julii meli moznost to udelat od zacatku spravne, proc pri preteceni se nenastavi nejaky priznak Overflow, a misto toho se tam nastavi 0 (ono 2^70). To je primo zhovadilost. Octave/Matlab tam hodi Inf, a hned vim ktera bije, ze musim dohledat nejakou chybu, at uz v rovnici nebo v programu.
Takze vlastne musim rict, ze me tenhle clanek od jazyku Julia docela odradil.
-
Nezatracujte Julii příliš brzy. 2^70 sice vyčíslí jako 0, ale 2.0^10000 vrátí jako Inf. Rozdíl je v tom, že v prvním případě pracuje s celými čísly a pro ně Inf není definováno. Ve druhém případě pracuje s číslem typu Float64 a tam už Inf je definováno v IEEE 754. Pokud si dobře vzpomínám, tak Matlab a Octave provádějí všechny operace v double.
Julia má mnoho velice přitažlivých vlastností, které se do úvodního článku nevešly: vícenásobný dispatching, provázanost s JIT, snadné externích volání knihoven a poměrně rozsáhlý balík vlastních knihoven. Počkejte si na další díly a třeba změníte názor.
-
gamer (neregistrovaný)
No jo, jenže python má virtuálně nekonečný int, nemusím řešit žádné typy...
>>> 2**700
5260135901548373507240989882880128665550339802823173859498280903068732154297080822113666536277588451226982968856178217713019432250183803863127814770651880849955223671128444598191663757884322717271293251735781376L -
robotron (neregistrovaný)
To ma Julca taky, akorat je ji potreba rict, ze ma pracovat s nim. A zaroven je rozhodne dobry, ze ma Julia krome bigintu i vsechny inty konkretnich bitovejch delek. Mozna patrite k skupine lidi, ktera uprednostni, kdyz si jazyk sam urci, v jakym typu se jede, ale me osobne takovy chovani pripada krajne nevyhodny.
-
Kiwi (neregistrovaný)
Začínal jsem na BASICu, pak Assembler, pak Pascal, pak C, pak C++, dnes mě živí i Java, ale od té doby, co do nás ve třeťáku na VŠ nahustili FORTRAN 77 kvůli numerice, dělám všechno, kde převažuje numerika, ve Fortranu 95 a zatím jsem nenarazil na nic, co by mě motivovalo to změnit. Množství odladěných knihoven - jak matematických, tak fyzikálních, tak technických, rychlost výsledného kódu, přímočarost při psaní programu, podpora polí, rozsáhlá komunita odborníků - to všechno dohromady zatím bezkonkurenční a popravdě mi uniká, proč se neustále někdo snaží to nahrazovat něčím jiným.
Máš ambice dělat numeriku seriózně? Nauč se Fortran. Konec konců je to jen nářadí, ale na seriózní práci je třeba seriózní nářadí, do něhož lze upnout standardní nástroje, a ne nějaká dětská sada na hraní.
-
Kiwi (neregistrovaný)
DSP bych snad ani numerikou nenazýval. DSP obnáší obvykle nějakou konvoluci, proveditelnou v Assembleru ve fixed-pointové aritmetice, a to co nejrychleji. Tím to hasne.
Numerikou mám na mysli simulace, výpočty s PDE, proudění v kotli, obtékání profilů, pružnost-pevnost, jaderně-fyzikální výpočty apod. K tomu jsou zapotřebí specifické knihovny, provádějí se tam poměrně náročné maticové operace, vedle řešení soustav například hledání vlastních čísel, počítání determinantů. Při výpočtech metodou konečných prvků se například výborně uplatňují fortraní schopnosti vysoce optimalizované extenzivní práce s poli. A rychlost kódu je taktéž dosti zásadní, je docela rozdíl, trvá-li výpočet týden nebo měsíc. On ten čas něco stojí.Opravdu mi nejsou jasné ty "oběti na čase a duševní pohodě". Možná by stálo za zvážení, zda se nevěnovat něčemu intelektuálně méně náročnému. "Oběti na čase a duševní pohodě" přinášeli především kolegové, kteří si vybírali nějaké své vlastní cesty, aby se pak ukázalo, že se v tom nakonec sami totálně ztratěj, vzdají to a utečou a celé to nakonec musí někdo udělat za ně. Ale tímhle se momentálně neživím, nicméně stejně pochybuji, že by zde došlo k nějaké revoluci.
-
robotron (neregistrovaný)
Ale to jsou mi moudra povyseneho rozumbrady :-) Tak ze sveho pohledu povyseneho rozumbrady pozmanem nasledujici:
- omezovat numeriku na FEMy mi prijde velmi omezene;
- pokud nedohlednete v DSP dal, nez ke konvoluci a filtrum zadanejm dvema vektorama koeficientu, pak to jen svedci o tom, ze o DSP nevite temer nic; namatkou, uplatnuju tam sirokou skalu maticovejch operaci vcetne operaci s ridkejma maticema, faktorizaci, atd. (Cholesky, QR, UDU, Sylvester, SVD,...). Opravdu nevim, jak jinak nez numerikou to nazvat. Krome toho zakladni operace vetsiny DSP technik je FFT a to je numerickej podobor sam o sobe;
- u tech FEMu a fortranska "vysoce optimalizovana extenzivni prace s poli" nejak netusim, jak se lisi od v.o.e.p.s p. v C nebo Julii; podotykam, ze ve Fortranu obcas pisu (velmi vzacne, F9*) a je mi znamo, jak ma ulozena pole v pameti, ale co znamena toto reklamni sdeleni, si bohuzel neumim predstavit;
- k tem obetem, to jste me pobavil: ja jsem v nejvetsi dusevni pohode, kdyz se prave *mohu* venovat necemu intelektualne narocnejsimu, nez jak (tupe, nezazivne a riskantne) zapsat elegantni myslenku neelegantnim kodem. Radsi tutez napisu o neco hezcim kodem.
- vlastni cesty v numerice moc nehledam, naopak se snazim pouzit neco, co dali dohromady chytrejsi. Julie jsem parkrat pouzil jako ucelnej nastroj na nektery ulohy, jimiz se zivim a bavim.
No ale jinak je samozrejme obcas potreba dat si pauzu a misto intelektualni cinnosti si treba pokecat ve foru, v tomto jsem s vami zajedno :-)
-
Kiwi (neregistrovaný)
To klidně přiznám, že nejsem žádný velký expert na DSP. Já tam opravdu dělal jen filtry a transformace a tím to hasne a nikoho jiného jsem taky neviděl, že by tam dělali kdo ví co. Ale dovedu si představit, že třeba u GSM a LTE technologií se mohou uplatnit i další metody, to je pravda. Jenže tam to asi stejně nakonec bude muset být přepsáno do Assembleru v kombinaci se specializovanými HW moduly, ne? Nebo u vás se věnujete nějakému hardcorovému postprocessingu signálů offline?
A čím ta Julie podle tebe tak válcuje ten Fortran? V jazyku samotném oproti Fortranu žádné killer features nenacházím, zato si dovedu představit problémy při kooperaci s fortraními knihovnami, s rychlostí kódu to asi taky žádná sláva nebude... Takže jednoduchá otázka - proč?
-
robotron (neregistrovaný)
Dekuji za rozumnou odpoved. Nejdriv k te Julii vs. Fortranu. Kooperace s fortrannima knihovnama je zcela v pohode a samozrejme se jich ohromna spousta vyuziva, na tom jsou postaveny i MATLAB/Octave/SciLab. Urcita vyhoda je v FFI. Jazykovou vyhodou oproti Fortranu uz je prave treba to, ze muzu volat map() a apply(), zrovna treba u optimalizacnich problemu se tohle hodi. Sirsi repertoar ciselnejch typu (od bitu po bigfloaty). Velmi prehledny napojeni ruznejch vysokourovnovejch I/O, ja jsem daval jako priklad ProtoBuf a SQL, ale urcite je spousta jinejch zdroju a cilu dat. Za killer-featuru povazuju ten system typu, diky nemuz je mozne: 1. jednu fci znovuvyuzit pro ruzne zpracovavane typy (aniz by je treba autor fce vsechny znal), ale 2. zachovat moznost optimalizujici kompilace.
(Jinak v modernim Fortranu jsem nedavno psal skutecne jen par malo radku (pouzivani ciziho SW baliku) a nutno rict, ze to nebyl tak odpudivej humus jako driv. Ale druh prace je to porad jinej nez v tech vysokourovnovejsich nastrojich.)
Ad DSP co delam(e): jednoduse receno od implementace v samotnem HW az po ten (post)processing na CPU. V soucasne dobe dokonce zvazuju, ze jednu vec v Julii necham bezet v realnem case na data blizici se Gb/s prijimana primo z druzice. U DSP (a teorii rizeni) jsou zajimave algoritmy jak behem samotne "filtrace" (tedy pruchodu signaly nejakymi systemy, regulatory a filtry), tak ve fazi "navrhu" (kdy je potreba ten filtr/regulator vytvorit) -- oboji je numerika, protoze ani ten navrh, krome specialnich pripadu, nejde treba resit analyticky. Nebo jde a stejne to vede na optimalizaci treba vahovanejma nejmensima ctvercema.
-
Kiwi (neregistrovaný)
Knihoven ve F77 je obrovské množství, většina. Ale není problém je použít i z F95, kód se dá použít i stylem copy-paste přímo ve zdrojáku, což je veliká výhoda.
F95 ještě OOP nemá, to se přidalo až ve F2003. Ale pomocímoduleatypese něco jako OOP dá udělat i ve F90, kdyby bez toho někdo fakt nemohl žít.
Výhoda F90/95 oproti F77 je v tom, že z Fortranu dělá normální strukturovaný modulární jazyk, který se obejde bezgoto, což F77 rozhodně není, odstraňuje pevný formát zdrojáku, odstraňuje 6znakové omezení délky identifikátorů a další nešikovnosti před-ASCII a děrnoštítkového původu, není už třeba čarovat scommonbloky, přidává dynamickou alokaci a mnoho užitečných (a přitom rychlých!) operací s poli a jejich částmi (m-tý řádek krát n-tý sloupec, každý n-tý prvek apod.) a rozšíření většiny matematických funkcí i na argument typu pole, což je pro numeriku fakt dost zásadní. Navíc tímto zápisem se spousta cyklů mění na implicitní, což dále zvyšuje přehlednost programu a možnost optimalizace překladačem. Tím, že to nejsou knihovní funkce, má optimalizátor překladače velikou výhodu a dokáže vyprodukovat i solidní paralelní kód, aniž by programátor pro to musel něco udělat. Použitímpure function,elemental subroutine,forall,where/elsewhere,codimension,syncapod. se dá překladači ještě dále pomoci v optimalizaci a program je navíc velmi přehledný.
Chápu, že F77 dokáže znechutit spoustu lidí, ale F90/95 už je normální, dobře čitelný, bezpečný a pro numeriku výborně uzpůsobený jazyk, jehož je F77 podmnožinou, F2003 dokonce objektový (ale to mi zrovna v tomto případě nechybí a pokud je mi známo, tak stejně většina lidí, kteří dnes tvoří nový kód ve Fortranu, bere za standard F95).
Chápu tažení proti F77, ale od té doby, co je F90/95, mi nikdo nebyl schopen vysvětlit, co má proti Fortranu. Pokaždé se totiž ukázalo, že ten jazyk dotyčný vlastně vůbec nezná.
Kdybych měl více času, tak bych třeba dal dokupy nějaký seriál o F95, abych ten jazyk a jeho schopnosti trochu přiblížil širším kruhům. On tu na rootu jakýsi seriál vycházel někdy před 10 lety, ale to bylo opravdu jen naprosté minimum.
Kdybych já chtěl vytvořit nějaký nový numerický nástroj s REPL, tak bych nevynalézal kolo, ale narazil bych to na moderní Fortran. To je to, co mi chybělo – nevím jak dnes, ale za dob mého doktorandování se k laborování používala Mathematica, Maple a Matlab a pak se to celé přepisovalo do Fortranu. -
atarist (neregistrovaný)
Ja mam prave dojem, ze to diky prekladu pres LLVM muze byt docela rychly. Je fakt, ze ty benchmarky linkovane z clanku jsou takove nijake, chtelo by to vice (mnohem vice) testu. Jinak nic proti Fortranu, Julia ma spis byt nahradou za Octave nebo R, nikoli za Fortran (vsak taky LAPACK tusim bere puvodni).
-
MMN (neregistrovaný)
Z FORTRANu bych blil. Přes tu musejní syntaxi bych se možná ještě přenesl, ale vzhledem k tomu, jakým stylem v něm daná část fysikální komunity pras^H^H^H^Htvoří, dokázal jsem si k němu vypěstovat značný odpor.
Céčko je z hlediska nástrojů s FORTRANem naprosto srovnatelné, a přinejhorším se dá nějaký extrabuřt psaný ve FORTRANu do céčkového programu nalinkovat.
-
robotron (neregistrovaný)
Jakozto clovek zivici se ze znacne casti numerikou musim rict, ze Julii vitam a podle me rozhodne *je* duvod pro jinej jazyk, nejen pro pod tim lezici knihovny.
Konkretni priklad, proc jsem Julii uvital: moznost rozumne pracovat v cislech s libovolnou presnosti. Tohle je neco, co treba do Matlaku kvuli jazykovejm omezenim dostanete jen s prisernou ztratou na vykonu a to jeste tak, ze budete rad, kdyz bude chodit + - * / a pak kdyz bude treba... co ja vim, treba najit koreny polynomu nebo provest netrivialni rozklad matice, tak smula, nutno implementovat znovu. Tady, kdyz nejaka funkce je naprgana pro "cislo", tak to proste bude fungovat i s nove zavedenym, nebo libovolnym dosud existujicim typem.
Dale, ten matlabi hnusnej datovej vsehotyp a fixace na to, ze jednorozmerne pole neexistuje jsou proste humus. Plus prijemnejsi prace s lambdama v Julii (apply...).
-
robotron (neregistrovaný)
Uvodem se zeptam, co je povazovano za nejpresnejsi merak v oblasti elmag v republice. Elmag je dost sirokej pojem, pokud je to jen mag., tak naposled vim jen o kariere pana soucasneho dekana FELu, postavene na jeho pokracovani v slepejich Fritze Primdahla z DTU. Ale mozna uz mame v republice i nejakej lepsi magnetometr, bylo by nacase (ze by opticke cerpani a <1pT?).
K cemu libovolna presnost: v praxi se mi to hodilo, co si vzpomenu, dvakrat. Jednak pri praci s presnym casem; narazite na metrologii, tak asi nemusim zduraznovat, ze jedna SI jednotka vladne (skoro) vsem (napriklad 1kg stale vzdoruje, ale snad ne nadlouho). 20 platnych mist se v praxi potka a to uz jsme na 64 bitech mantisy (!).
Druhej a mnohem zajimavejsi protoze mezioborovej duvod pouziti presny aritmetiky u me byl, kdyz jsem potreboval kratit nejaky polynomy v teorii rizeni. (Konkretne: Wieneruv filtr.) Sice lze k vysledku (mozna) dojit i aplikaci jinejch numerickejch metod, ale mne konkretne se zalibila moznost proste misto toho, abych problem prevedl na faktorizace matic (a jiny hruzy, ktery by v dany uloze dost mozna dojely opet na numericky potize) proste zustat u kraceni polynomu, akorat jejich koreny diky te libovolne presnosti mohly byt vycisleny natolik presne, ze se kraceni seslo. (Zaujalo to i meho profesora ridici techniky. Zel jsem neprisel na zobecneni metody pro MIMO systemy, ale to uz zabihame do podrobnosti.)
-
K> (neregistrovaný)
cas jsem cekal, ale skoda ze jste nerozvedl detaily. svetova porovnani ukazuji nejlepsi nejistoty v radu 10^(-15), ve vyzkumu jsou zdroje frekvence nekde na radu 10^(-18). ale s timhle se clovek bezne (chapej mimo 10 metrologickych institutu na svete) nesetka, a nema smysl aby v techle presnostech pocital.
tedy porad bohuzel nechapu, kde v praxi potkate 20 platnych mist?
jinak v elmag je to josephsonuv etalon, relativni nejistota 10^(-10), neboli pokud se pri vypoctech naakumuluji chyby na radu 10^(-11), tak to nema zadny vliv na vysledek.
jde o relativni hodnoty. samozrejme pokud by clovek meril napr. picotesla, tak nema smysl pocitat treba v megatesla. pokud clovek napise rovnici tak blbe, ze se mu michaji ve vzorci rady v obrovskem rozsahu, tak pak libovolna presnost je treba, ale je to hloupost a zbytecnost.
-
robotron (neregistrovaný)
Detaily sem asi nepatrej, ale nebranim se podrobnejsimu popovidani, koneckoncu, snad se behem cervna dostanu i do Brna. Ano, mj. i svetova porovnani jsou to, co resim. Pro me je to tedy praxe a otazka, kde v praxi, je zodpovezena. V geodezii se bezne prumeruji casove rady trvajici nekolik let, tak tam uz se tech platnejch mist nasbira hodne i pri uvazeni toho, ze apriorni stredni hodnoty odecitame.
Ad pT vs. MT: to je samozrejme pravda a plati to napric obory.
-
robotron (neregistrovaný)
Cisla pro koncovy uzivatele skutecne muzou nejakejch ~10 platnejch mist mit. K tem cislum je ale potreba nejak dojit, (ridky) soustavy o milionu rovnic nejsou nic neobvykleho. To i s velmi dobrejma numerickejma algoritmama uz je vyzva. (Nicmene stale jich vetsina jede na doublu, aspon pokud vim -- jen je potreba znacne opatrnosti.) Puvab presne aritmetiky je v tom, ze muzu napriklad konzistentne ulozit data. To jsou treba roky casovejch znacek s rozlisenim v radu ns..fs (podle toho, v kterem jsme desetileti). Samozrejme si misto toho muzu delat nejaky vlastni struktury z intu (a v C to tak delam, koneckoncu, dela to tak kazdej, viz struct timespec ci NTP datum), ale je to dost nepohodlny.
Uvadel jsem vyse ale i jinej zajimavej zpusob vyuziti libovolne aritmetiky, a to na kraceni polynomu, coz je v DSP/teorii rizeni uzitecna operace a tradicne se to tak nedela, tradicne se pouzivaji brutalne slozite algoritmy primo na dane faktorizace (viz treba SLICOT). Ale i ty maji nekde meze a pokud mam u atomovejch hodin specifikovanou presnost se zlomama spektra sumu rozlozenejma pres 5 radu, pak to ani nejlepsi (tradicni, doublovy) algoritmy proste nedavaj, nebo stezi.
-
Pavel TišnovskýZlatý podporovatelPodle me nejde ani tak o presnost jedine hodnoty, co vyleze z meraku (nebo serie hodnot), ale o vypocty. Uz jenom par stovek souctu nad floaty/doubly vede k mnohdy monstroznim chybam, nehlede na nekomutativitu a neasociativitu vsech operaci. + problemy s cisly typu 0.1 (nelze presne reprezentovat) vedou k tomu, ze napriklad operace v bankach se s float/double nedaji rozumne delat.
-
J (neregistrovaný)
Což obvykle svědčí o špatně podmíněných algoritmech. V takových případech výpočty s libovolnou přesností příliš nepomáhají. Trochu ano ale nešikovně zvolený algoritmus může velmi rychle divergovat k nesmyslným výsledkům.
Komutativní zákony ve výpočetní technice nebudou obecně platit nikdy. Jestliže má číslo 0.2 nekonečný binární rozvoj, k jeho přesnému zobrazení v počítači je potřeba nekonečná paměť. Za mých mladých let to byl problém a mám takové temné tušení, že je to drobný technický problém do dneška...
-
Pavel TišnovskýZlatý podporovatel
Buď špatné algoritmy nebo špatně zvolené datové typy :-) Typicky pokud víme, že 0.1 nelze v IEEE 754 floatech reprezentovat, tak volbou tohoto typu na výpočty, kde se používají desetiny a setiny (centy, halíře - vše musí být podle zákona), si zaděláváme na problém a mnoho programátorů mě do očí tvrdí "ale s doublem už to bude v pohodě, ten je _přesný_".
U některých výpočtů je například lepší se spolehnout na zlomky, samozřejmě pokud se pracuje s racionálními čísly atd.
IEEE 754 je jen jedna z možností, jak reprezentovat floaty, používají a používaly se i další formáty:
http://www.mrob.com/pub/math/floatformats.html(zajímavé mohou být ty formáty, kde je B=10 nebo B=100, protože tam s 0.1 problém není, samozřejmě zase bude problém s jinými hodnotami, záleží na tom, co a jak je potřeba řešit a jak rychle - třeba místo floatů jít do fixed point apod.)
-
JS (neregistrovaný)
> je to drobný technický problém do dneška
Tak treba IBM zSeries mainframe (procesor) ma uz par let dekadicka cisla v plovouci radove carce.. (Mimochodem je to docela zajimave udelane, pouzivaji kodovani 3 cifer do 10 bitu.) Takze reprezentovat 0.2 fakt neni problem. Casem se mozna podobny koprocesor dostane i do beznych PC.
-
K> (neregistrovaný)
hm, matlab/octave jsem v te tabulce http://www.mrob.com/pub/math/floatformats.html nenasel, ale zkusil jsem v octave secist cislo 0.1 10^8krat, a relaivni chyba byla ~-2^(-9). to mi neprijde az tak katastrofalni.
-
atarist (neregistrovaný)
To ovsem nic nerika o tom, jak ta chyba oscilovala kolem spravnych hodnot.
S 0.1 je to s floatama sranda, napriklad (pochopitelne) neplati, zesuma deseti 0.1 == 1.0
takze typicky skolni priklad na nekonecnou smycku:
#include <stdio.h>
int main(void)
{
float f;
for (f=0.0; f!=1.0; f+=0.1) {
printf("%f\n", f);
}
return 0;
}no a tak je to se vsim :) protoze != a == na floaty se proste nesmi pouzivat! (jen fabs(x,y)<delta)
-
atarist (neregistrovaný)
To je pravda, v tomto pripade to pujde (pokud se striktne zachova typ, tj, zadne float to double apod.). Ale obecne se na tyto operace spolehnout neda a musi se striktne porovnavat abs s nejakou deltou - coz je fajn, clovek si aspon presne uvedomi, co vlastne znamena "rovna se" a s jakymi hodnotami dela.
-
robotron (neregistrovaný)
"Naopak me zarazi, ze pokud autori Julii meli moznost to udelat od zacatku spravne, proc pri preteceni se nenastavi nejaky priznak Overflow, a misto toho se tam nastavi 0 (ono 2^70). To je primo zhovadilost."
Naopak! Ja jsem moc rad, ze to konecne udelali spravne, tedy tak, ze kdyz pracuju s intama, chova se to intove, kdyz s floatama, tak floatove atd. Koneckoncu, kdo je opravdu numerik, tak by na to mel bejt zvyklej i z praveku, nebot ve Fortranu (a C) se taky chova jinak "0" nez "0.".
Lidska disciplina nutna k tomu vybrat si datovej typ a psat konstanty podle nej je zde uplne minimalni a zisk v tom, ze jazyk dela, co potrebuju a ne nejak umele-inteligentne zvolenou kravinu, je ohromnej.
-
K> (neregistrovaný)
Pro mne osobne je ta nutnost vybirat si datove typy spis otravnost, dana vyvojem a omezenim pocitacu. Nejsem ajtak, a kdyz to nemusim resit, tak mi to umozni soustredit se na tu matematiku, a ne na psani zdrojoveho kodu.
Kdyz si pocitam na papire, tak taky neresim jesli pisu inty nebo floaty :)
-
robotron (neregistrovaný)
Pokud na papire neresis, jestli vysledek vysel celociselne, tak to nekdy muze znamenat tak drasticke rozdily, jako jestli pracujes se sumem nebo s periodickym signalem. Pokud na papire neresis, jestli vysledek je realne nebo komplexni cislo, pak se asi mijis s celou existujici algebrou. To nemluvim o telesech, okruzich a vubec algebre jako takovy -- to je system typu (objektu) a funkci nad nima par excellence.
Ja na papire resim intovost, floatovost a complexnost pokazdy a vyzaduji, aby mi v tom pocitac nedelal o svoji vuli bordel ;-)
-
Pavel TišnovskýZlatý podporovatel
Jde o to (mozna jsem to mel vic zduraznit), ze typovy system Julie je sice dynamicky, ale striktni. Takze kdyz chcete pracovat s integery, bude se pracovat s integery a neni tam zadna automagie, ktera by najednou prepnula na floaty (coz je stejne blbost, protoze se ztrati nejnizsi cifry, takze budme radi, ze to neumi :). Kdo chce floaty, primo je specifikuje, stejne jako ve Fortranu atd. No a pokud si je nekdo jisty, ze pro numericke vypocty potrebuje BigInt nebo BigFloat, tak je pouzije. Navic je mozne (to jsem zatim nezminil) u floatu ridit rezimy zaokrouhlovani, nejedna se o zadnou raketovou vedu, ale je dobre to vedet a kdyztak pouzit.
Ale chapu, ze nekomu to nemusi vyhovovat, me napriklad nevyhovuji systemy, kde se automaticky prevadi (u nejakych operaci) int->float/double bez moznosti to ovlivnit.
