Názory k článku
Fraktály v počítačové grafice IV

To je sice hezké, ale pořád mi tu chybí pointa.
Vezměme si např. "klasiku" - Mandelbrotovo jabko. Je poztaveno na úplně primitivním vzorečku (tuším) :


Z(n+1) = (Z(n))^2 + c

Z tohoto strohého vyjádření ale vznikne (relativně) krásný objekt.

Při běžném nahlédnutí je jasné, že musí existovat 2 oblasti :
- konvergovat budou čísla blízká nule
- divergovat čísla s absolutní hodnotou mnohem větší než nula.

Z toho dále vyplývá, že musí existovat hraniční body, v jejichž okolí se bude takto popsaný "konečný stav" (tj. stav po předem zvoleném počtu iterací) měnit z jedné oblasti na druhou.

Z poučky "všechno je v přírodě účelné a jednoduché, zmatek do toho vnáší až člověk" by pak vyplývalo, že hranice bude mít tvar nějakého jednoduchého objektu (kružnice, srdcovka - vzhledem k tomu, že (i)^2 = (-i)^2 měl by být symetrický podle reálné osy).
Tolik úvaha selským rozumem.

A teď bych rád viděl nějaké stručné a snadno pochopitelné vysvětlení, _PROČ_ se se tvar takto jednoduše popsané množiny tolik komplikuje ?!? JAK je možné, že z něčeho tak jednoduchého vznikne něco tak složitého ?
Na rozdíl od "reálných" fraktálů (tvar osrova apod.) jde o čistě abstraktní matematický problém. A matematika přece vždycky byla (s vyjímkou fraktálů) krásně učesaná.

P.S. Jinak samozřejmě děkuji autorovi a redaktorům za krásný seriál !

No právě že ta hranice mezi body, které konvergují k nějaké konečné hodnotě (ne nutně k nule) a mezi body, které divergují je dost složitá - má H. dimenzi rovnu dvěma, je nekonečně členitá a je to jeden z nejsložitějších tvarů v rovině vůbec.

Začít hned zkoumat M-set je dost divoké - ten vzoreček je totiž na nějaké podrobnější průzkum až moc složitý (už jenom díky komplexním proměnným). Lépe se některé aspekty ukazují právě na logistické funkci, která je definována nad reálnými hodnotami. A dokonce mezi logistickou funkcí, bifurkačním diagramem a M-setem existuje několik vazeb.

Ta poučka "všechno je v přírodě účelné a jednoduché, zmatek do toho vnáší až člověk" je už z principu subjektivní - co je to "účelné" a "jednoduché". V přírodě se vyskytují v hojné míře objekty, které určitě nejsou jednoduché, složitost je třeba vlastní všem živým organismům (i těm nejjednodušším). Ta zjednodušující pravidla zavádí právě člověk, aby si (alespoň mentálně) přírodu podmanil, ale jak je patrné například právě z fraktální geometrie, turbulencí, teorie chaosu a principu neurčitosti, ono je to o dost složitější... :-)

chyba je hned na začátku
ono totiž tvrzení:
"všechno je v přírodě účelné a jednoduché, zmatek do toho vnáší až člověk" vůbec není pravdivé ;)

A? nebo? anebo? Bílý šum není gaussovský? Bílý šum jen nekorelovatelný gaussovský šum. Korelovatelný gaussovský šum je barevný šum, neboli také bílý šum po průchodu lineárním dynamickým systémem. Jakýkoli jiný (negaussovský) poruchový jev lze modelovat průchodem bílého šumu skrz nelineární systém. Neboli jsem nepochopil co je to Gaussovský generátor a jestli se to nějak vylučuje s generátorem bílého šumu a proč je mezi nimi spojka nebo a proč nestačilo napsat generátor šumu (poruchového jevu).

Z Wikipedie (http://en.wikipedia.org/wiki/White_noise):

It is often incorrectly assumed that Gaussian noise (see normal distribution) is necessarily white noise. However, neither property implies the other. Thus, the two words "Gaussian" and "white" are often both specified in mathematical models of systems.

Odhlédněme od toho, že Wikipedia není spolehlivý zdroj informací a na její definice bych se moc nespoléhal. V podstatě se v tomto konkrétním s ní dá souhlasit. Bílý šum může být negaussovský, stačí aby byl nekorelovatelný a gaussovský šum nemusí být bílý, mezi gaussovské šumy patří i barevné/korelovatelné šumy. Proto by mě zajímalo z jakého důvodu jste si vybral právě gaussovské nebo bílé šumy, když to mohou být gaussovké a bílé šumy, ale také gaussovské barevné a negaussovské bílé a v neposlední řadě dokonce negaussovské korelovatelné (barevné). Prostě mě zarazilo to použití dvou nesoumřitelných kategorií gaussovský a bílý v místě, kde stačilo napsat "šumové generátory". Takto napsáno to může vyvolat dojem, že ty generátory mohou být jen gaussovské a bílé, nebo dokonce mohou být pouze gaussovské barevné a negaussovské bílé, pokud to nebo chápeme jako xor.

Mě se to nechtělo hledat ve skriptech, tak jsem aspoň plácl o Wikipedii (zrovna jsem ji měl otevřenou na jiném hesle :-) Ale máte pravdu v tom, že ta věta je napsána nešťastně a může to někoho zmást. V demonstračních případech to bude mnohem jednodušší, tam se bude G. šum nahrazovat několikerým voláním rnd() :-)

Aha, takže ani bílý ani gaussovský, ale nedokonalý pokus o model :-D

Ne, správně by se měl používat generátor bílého šumu. Ten se však na počítači bez přidaného HW generuje dost složitě (možná tak čtením mikrofonního vstupu), takže v demonstračních příkladech, které pouze implementují část teorie, se to o dost zjednodušší.

Podobný přístup například použil i Perlin při vytváření jeho (Perlinovy) funkce, kde je také použita rnd() místo "onačejších" nástrojů :-)

Jak pro danou Hausdorfovu dimenzi vyrobit odpovidajici frekvencni spektrum?

Ne ze bych vam neveril, ze je LOGO zalozeno na LISPu (kdyz to tvrdi i dalsi) ... ale docela by me zajimalo, jestli se to projevovalo v praxi na implementaci, na ktere jsem se LOGO kdysi davno na PC XT ucil ... nepamatuju si zadnou praci se seznamy. Ani ukladani stavu zelvicky mimochodem. Pravda, je mozne ze jsme se k tomu nedostali.

Funkcni model LOGA byl opravdu naprogramovan v LISPu (spolu s mechanickou zelvickou :-) a v teto podobe byl (a stale) je sirena jedna z dostupnych verzi. Posleze se samozrejme vytvarely i verze v jinych programovacich jazycich, na osmibitech zejmena v assembleru.

LOGO podporuje praci se seznamy, vybiram par zakladnich prikazu:
empty? first foreach is-list? item last length list map member? remove remove-duplicates remove-item replace-item reverse sentence sort sort-by sublist

Seznamy se zapisuji v hranatych zavorkach (protoze, podobne jako v LISPu, i sekvence prikazu je seznam).

rad bych si vygeneroval obrazky 1 a 2 abych se na ne mohl trochu podivat. existuje soft ktery je vygeneruje?
diky
d.

k tej 4d juliovej mnozine:

http://www.devmaster.net/forums/showthread.php?t=4448

;)

Prvni obrazek je vytvoren v programu POVRay (jedna se o raytraces s pridavnymi funkcemi pro vypocet energii pomoci radiacni metody - radiosity). Tento program od sve verze tusim 3.1 podporuje i 3D rezy puvodni 4D Juliovy mnoziny. My ve svych demonstracnich prikladech tak daleko nepujdeme a misto raytracingu se bude vyuzivat "sumace" hodnoty pixelu v jednotlivych rezech.

Druhy obrazek jsem vytvarel pomoci vlastniho programu, ktery samozrejme zverejnim v jednom z dalsich pokracovani tohoto serialu - az se budeme zabyvat dynamickymi systemy. Ve sve podstate se vsak nejedna o nic jineho, nez o zobrazeni "orbitu" Mandelbrotovy mnoziny.

Misto poctu iteraci, ktere se bezne prevadi na barvu nebo odstin sedi, se primo vykresluji pozice pocitanych bodu z_n (ze znameho vztahu z_{n+1}=z_{n}^2+c}). Aby ten obrazek vypadal pekne, je nutne rucne doladit pocet iteraci, pocatecni iterace, kdy se body nevykresluji atd.

Celkem bych uvital i ukazky kodu, ktere dany obrazek vygenerovaly. Alespon hlavni algoritmy

Dobrý den, přemýšlel jsem, zda by měly být pro název IFS přenesením do češtiny použito spíše IF systémy, než IFS systémy?