neni tohle trochu divny???
kdyz mam pak funkci vrat_mi_dalsi a pouziji ji na "stejnym radku", tak dostanu stejne vysledny :// podivne...
jinak ale co zatim procitam dokumentaci, tak mi to trochu pripomina rozdil mezi C++ a D ... tohle vypada jako logicky nastupce oo-pascalu...
Poznámka
V Flexu se automaticky předpokládá, že funkce vrací v rámci jednoho výrazu při stejných
parametrech vždy stejný výsledek. Jinak řečeno to znamená, že například výraz
ziskej_cislo(x)+ziskej_cislo(x) překladač považuje za plně ekvivalentní
výrazu 2*ziskej_cislo(x) a podle toho také provádí případné optimalizace výrazů.
Oblíbená "céčková" konstrukce getbyte(soubor)+256*getbyte(soubor) je
tedy ve Flexu chybná!
Po pravde receno se mi tahle myslenka taky moc nelibi (mmch v optimalizatoru se zatim neuplatnuje), ale jde proste o terminologii.
Od matematicke funkce taky nepredpokladate, ze bude vracet pokazde jinou hodnotu. Predikat v Prologu taky musi pokazde vratit pro stejne vstupy totez (IIANM).
Kdyz je to funkce, vraci to pro stejne vstupy totez.
Tudiz random nebude funkce, ale procedura s vystupnim parametrem, nebo to bude funkce, jejimz parametrem bude seed (=predchozi nahodne cislo), cimz dosahnu i toho, ze nebudu mit nekde mysteriozne skrytou stavovou promennou (jak v cecku dosahnete nekolika nezavislych RNG, resp. thread-safe RNG?).
jak v cecku dosahnete nekolika nezavislych RNG, resp. thread-safe RNG?
jednoduse, naprogramuju si vlastni :O)
bud v C++ kde to bude trida a jednotlive generatory jaji instance, nebo v C++ proste nejaky struct co bude obsahovat seed a ten bude jako jeden z parametru. Naprogramovat zakladni random typu
seed=seed*konst1+konst2;
return "nejake nizsi bajty ze seed"
je pomerne jednoduchy.
BTW od standardniho randomu obvykle neocekavam nejakou nezavislost nebo opakovatelnost, proste cekam nahodna cisla (i kdyz ve skutecnosti jsou jen vice ci mene pseudonahodna pokud nemam hardwarovy generator sumu nebo tak neco)
Ano, obecne tam musi byt mod (no na ten jsem pozapomnel, jinak by ty cisla lezly do nekonecna), ale tady pocitame s 16/32/64/buhvikolika bitovou aritmetikou, kde se mod (2^pocetbitu) dela tak nejak automaticky :O)
No to ja samozrejme s 16/32/64/buhvikolika bitovou aritmetikou pocitam, jenze pokud ji pouzivas jako nahradu mod, tak neber dolni bity, protoze nejsou moc nahodny (presneji receno, 1 dolni bit ma periodu nejvyse dve, tzn. bud je porad stejny, nebo se pravidelne strida 0,1,0,1, ..., 2 dolni bity maji periodu nejvyse 4, 3 dolni bity 8, ...). Bud ber horni bity, nebo tam dej modulo treba 2^32-1.
Ale ted uz jsme offtopic i na tehle diskuzi. :-)
Upřímně řečeno toto pravidlo je zatím stále "ve vývoji" - jinými slovy si to možná ještě rozmyslíme ;-) Fakt je ten, že Flex má bojovat s chybami a zavést konstrukci, která bude sice formálně dobře zdůvodněná, nicméně velké části programátorů přijde jako minimálně nezvyklá, by mohlo chybám spíše napomáhat... A jak už psal Petr Kadlec, tak optimalizátor toto pravidlo zatím nevyužívá.
