Hlavní navigace

Vlákno názorů k článku Obsah jednotlivých částí seriálu a galerie fraktálů od patlálek - Tak tenhle seriálek, to je tedy materiálek... Fraktálním...

  • Článek je starý, nové názory již nelze přidávat.
  • 5. 6. 2007 0:26

    patlálek (neregistrovaný)
    Tak tenhle seriálek, to je tedy materiálek... Fraktálním obrazcům se obdivuji už asi 10 let, první jsem objevil náhodou v programu FractInt tenkrát to jelo ve Win 3.11 na 286ce a monochromu. Nehledám v tom žádné praktické využití, jen tu krásu a podivuhodnou podobnost s přírodou.
    Zvykl jsem si na Visual C++ 6.0 a všechny příklady se pokouším přepatlat do tohoto prostředí, pro grafiku používám funkce API.
    Vypadá to taky dobře. Nebyla by nějaká transformační matice pro fraktální IFS větvičku? Z výkladu jsem to nějak nepochopil.
  • 5. 6. 2007 10:38

    Pavel Tišnovský
    Taky jsem s FractIntem začínal na 286ce. Dokonce jsem si nakonec z výprodeje pro FractInt a programování koupil koprocesor 287 a nakonec byly výpočty rychlejší než na 386ce (40MHz) s emulátorem 387 :-)

    Uvažoval jsem o tom vytvořit nějaký rozšiřitelný program na tvorbu fraktálů. Spíš něco na detailní zkoumání, tj. ve stylu FractIntu, ne XaoSu. Výpočetní smyčky samosebou v céčku, ale zatím nevím, co použít pro GUI.

    Zkoušel jsem různé toolkity (FLTK, wxWidgets, QT, GTK), ale je to všechno takové molochoidní a kromě wxWidgets to také např. na Windows nevypadá nativně. Asi mi zbyly dvě možnosti: Windows verzi postavit nad API (taky mám rád VC6) a pro zbylé platformy použít QT/GTK, nebo GUI naskriptovat v TCL/TK.

    Definici pro fraktální IFS větvičku dodám zítra, potřebné definiční soubory s maticemi mám doma.
  • 5. 6. 2007 10:58

    anonymní
    Serial se mi take velice velice libil. Na GUI by se mozna dalo pouzit WPF. Bude vypadat nativne a hezky se s nim pracuje. Co vy na to?
  • 5. 6. 2007 11:42

    Pavel Tišnovský
    Pro me je trosku omezujici podpora pouze XP a W2003. Na domacim pocitaci mam krome Linuxu jeste Windows 98 a nic dalsiho se mi kupovat nechce (nehlede na to, ze by to ten strojek taky nemusel utahnout :-). Ale mrknu se na to, GUI toolkity me zajimaji a i proto je me lito, ze vetsina z nich je takova nedotazena (snad krome Qt, ale to je o mnoho vic nez GUI toolkit).
  • 5. 6. 2007 12:19

    Pavel Krejčíř
    Pánové, fraktály se mi líbí, ale spíš okrajově. Chtěl bych si přisadit něco k tomu GUI. Po letech používání nejrůznějších RADů a podobných nástrojů, jak v práci, tak pro zábavu, jsem dospěl k závěru, že jsou všechny do jednoho na H... Vyzkoušel jsem Delphi (skoro všechny verze), VC, VB, .NET. Pomocí všeho uděláte rychle okýnka a akce na klikání, ale nakonec zjistíte, že nic není dokonalé. .NET zavrhuju rovnou, jako něco naprosto nepoužitelného. U dalších postupně narazíte na problémy, které se projeví až po čase. Až na VC má většina nástrojů naprosto mizernou nebo žádnou prodporu pro lokalizaci (přepsání stringů do jiných jazyků). Při přechodu na novější verze Windows to najednou přestává fungovat, nebo jsou okénka hnusná a není na nich vidět všechno. Údržba kódu je čím dál tím težší, a běda, jak něco nedělá co má. Navíc většina RADů namastí do resourců i jinam spoustu věcí, o kterých nikdo nestojí.

    Nakonec jsem dospěl k tomu, že absolutně nejbezpečnější je vytvořit GUI pomocí Windows API přímo. Při přechodu na Linux už jsem pak nic neřešil a rovnou sáhl po GTK+ 2.0. To je úplně v pohodě, aplikace zkompilovaná pod GTK běží bez překompilování na jiných distribucích a to pod GNOME, KDE i xFce, takže asi pod vším.

    Na začátku to vypadá, že je to víc práce, ale ujišťuji vás, že se to vrátí, a to rychle. Takže pokud nestojíte o nějaká "fency" okýnka stylu WinAmp nebo Media Player, doporučuji pro Windows napsat okna pomocí API a zkompilovat MinGW-čkem a pro Linux napsat okna pomocí GTK+ a zkompilovat g++ -kem. Střeva pak budou moct být úplně stejná pro obě platformy, GUI bude rychlý (nejrchlejší) a poběží od 95 po Visty a od RetHatu po Xubuntu.

    Nakonec, abych nevypadal, že tu planě plácám, tak pokud máte nějakou představu, jak by to GUI mělo vypadat, tak mi to pošlete a jám vám ty okýnka namastím.

    Přeju hezký den.
  • 5. 6. 2007 12:29

    Pavel Tišnovský
    Moc mě těší, že na tu věc má někdo podobný názor jako já. Na Windows jsem nakonec také skončil tam, kde jsem začal, tj. na čistém WinAPI. Trošku problém mám s dialogy, ani ne tak s jejich vytvářením (resource dělám ručně), ale potom se smyčkou zpráv a následným zpracováním dat. Ne že by to bylo nějak extra složité, spíš je to pracné a bojím se, aby ta aplikace neskončila jak některé další open-source aplikace: funkční, ale GUI zprasené (protože je jednodušší upravit algoritmy než šahat na GUI).

    Samozřejmě okénku bych chtěl mít stejná, jako u ostatních nativních aplikací (+klasická menu a základní sadu widgetů), právě ty "výstřelky" uživatele pěkně matou, nekledě na složitější automatizaci těchto aplikací (třeba nejde poslat zprávu widgetu, který z hlediska WinAPI ani widget není).
  • 5. 6. 2007 12:31

    Pavel Tišnovský
    Zapoměl jsem dodat, že na Unixech (Linux, SGI) jsem si většinou vystačil s Tcl/Tk (+volání céčkových programů), ale dnes už je problém s některými Linuxovými distribucemi, které Tcl/Tk v základní sadě neobsahují.
  • 5. 6. 2007 13:28

    Pavel Krejčíř
    Tcl/Tk neznám, ale jak jsem se letmo podíval, co to je, tak bych do toho nešel. Moc to zavání vším tím, co jsem popsal v předchozím dopise, a co nechci. Jo, já RADy plošně neodsuzuju, jsou užitečné k rychlému napsání malé utilitky. Ale z vlastní zkušenosti už vím, že založit na RADu nějakou větší, komplexnější aplikaci, s ambicema na dlouhodobou údržbu a vývoj, je chyba. Rovněž je chyba vyvíjení vlastních kontrolů/widgetů. Dá se to, ale jen v krajní nouzi.

    Ale zpátky k tomu problému. Samozřejmě, že GUI napsané v API představuje trochu víc kódu. Je potřeba to dobře strukturalizovat, třeba rozházet do víc souborů. Výhoda je, že v kódu pak není nic, co opravdu nepotřebuješ (pokud to teda někdo opravdu nezmastil), a když tam něco nefunguje, snáz se to najde a opraví.

    Na X bych fakt doporučil to GTK+. Já to vyzkoušel na Xubuntu a jde to dobře. Je k tomu kvalitní dokumentace a spousta ukázkových příkládků, a strukturou se to dost podobá Windows API. Ve skutečnosti je to ještě jednodušší, protože do smyčky událostí se registruje pomocí callbacků, což umožňuje napsat o něco přehlednější kód. Těma callbackama už to trochu připomíná RADy, ale domnívám se, že GTK+ je nejnižší použitelná úroveň pro programování GUI (nic nižšího jsem už neobjevil). Jo a taky to jde lehce zkompilovat na 64bit.

    A teď už nevím, co jsem vlastně chtěl napsat, tak končím.
  • 5. 6. 2007 15:36

    Pavel Tišnovský
    Tcl/Tk je trošku jinde, než klasické RAD, ve kterých se GUI naklikává. Tady jde o programovací skriptovací jazyk (Tcl) s přidaným toolkitem (Tk), který se snaží (alespoň na Windows a trošku i na Mac OS X) tvářit nativně, i když běžný widget set dost rozšiřuje. Celé se to chová na velmi vysoké úrovni, vlastně jde o úplný opak API. Například je možné na canvas vkládat objekty, které je možné kdykoli změnit, přidat k nim callback funkce atd.

    Tcl/Tk je ideální pro psaní aplikací, u kterých ještě není jasné, co mají přesně dělat (a takových aplikací je celkem dost), problém však bývá s instalací SW. Pro vnitrofiremní aplikace to však problém není, stejně jako pro rozsáhlé projekty, které stejně musí nakonfigurovat administrátor.
  • 5. 6. 2007 14:08

    anonymní
    Myslim, ze by mela byt podpora v projektu mono: http://www.mono-project.com/Mono_Project_Roadmap

    The WPF abstraction is anything but MS-centric. It’s just that MS are the only ones who have implemented it yet. Wait for Mono to implement WPF and then look forward to having your WPF applications running on Linux in Firefox. The Mono guys themselves have stated that WPF support would be *easier* to implement than Winforms, and that’s because it’s not an MS-centric abstraction.

    http://www.theserverside.net/news/thread.tss?thread_id=42026
  • 5. 6. 2007 13:28

    ava (neregistrovaný)
    FLTK rozhodne neni molochoidni ( z dokumentace k 1.1:

    * sizeof(Fl_Widget) == 64 to 92.
    * The "core" (the "hello" program compiled & linked with a static FLTK library using gcc on a 486 and then stripped) is 114K.
    * The FLUID program (which includes every widget) is 538k
    )

    Docela prijemne se s tim programuje, pokud clovek chce neco s cim autor nepocital, daji se zdrojaky snadno upravovat :)

    Jediny problem je schizofrenie verzi - jako stabilni je oznacena 1.1, ale na verzi 2.0 se pracuje jiz nekolik let - sice aktivne, ale dlouho.

    Napsal jsem ve FLTK sice jen jeden mensi programek - ale FLTK si urcite na veci ktere se maji rychle spoustet a zabirat malo pameti sve misto pod sluncem zaslouzi.

    Nativne sice pod windows nebezi, ale az zas tak odlisne nevypada..
  • 5. 6. 2007 14:41

    Pavel Tišnovský
    Zrovinka vcera jsem FLTK zkousel jak na Windows, tak i na Linuxu (Debian) a nevypada to spatne. Trosku u me ztraci tou ne-nativnosti, naopak se mi libi emulace GLUTu. Ja nevim, ale Hello world na 114kB je docela dost, ne? S nativnim widget setem (+nejakou nadstavbou nad nim) se da dostat pod 10kB :-) V tomto ohledu nejlepe vypada wxWindow, ale musi se vhodne zvolit, co s programem slinkovat.
  • 7. 6. 2007 8:42

    anonymní
    K tomu wxWindows/wxWidgets:
    molochoidni skutecne je, ale UPX (ultimate packer for executables) utilita s velikosti udela divy. Vrele doporucuji, velikost vetsiho programku se smrskne na zlomek puvodni velikosti. Ostatne UPX doporucuji i na samotnem wxWidgets.org.
  • 7. 6. 2007 8:46

    ava (neregistrovaný)
    wxWindows jsou vynikajici, osobne je mam ze vsech toolkitu nejradeji - ale nejsem si jisty, jestli jsou delane pro staticke linkovani. Bezne se pouzivaji na velke dynamicky linkovane aplikace a samotna knihovna (.so nebo .dll) par MB ma..
  • 5. 6. 2007 14:09

    honza (neregistrovaný)
    jestli chcete multiplatformovost a netrapi vas trochu vyssi naroky na pamet, pak doporucuju javu + swing - je to vcelku jednoduche. da se to i trochu nastavit, aby to vypadalo jako nativni windows aplikace.
  • 5. 6. 2007 14:33

    Pavel Tišnovský
    Ano, se Swingem jsem par veci udelal, dokonce i se starym hnusnym AWT. Ale nejsem si jisty, jestli zrovna aplikace pro generovani fraktalu by mela byt v Jave. Teoreticky je na tom s rychlosti podobne jako neoptimalizovane cecko (nejake benchmarky jsem uz zkousel), ale spis me odrazuje pomalost aplikaci v Jave s GUI - napriklad veci od Oraclu ale i JEdit ci NetBeans rychlosti neoplyvaji (stejne jako jeden graficky editor, na ktery tady vysla recenze ci upoutavka. Na jmeno si nevzpominam, ale pomale to bylo strasne).

    Ale pravda je, ze o Jave+Swing taky uvazuju. Asi si zkusim napsat nejaky testovaci programek a tu rychlost vyzkouset.
  • 5. 6. 2007 15:43

    honza (neregistrovaný)
    v jave programcim, neco malo i ve swingu, ale nic vetsiho s grafikou jsem jeste nedelal, takze s rychlosti nevim, asi bude lepsi to opravdu napred vyzkouset. Jasny je, ze java asi neni optimalni jazyk na grafiku, ale zase se to da nabusit relativne rychle, jedete to vsude kde funguje java a jazyk i vyvojovy prostredi jsou zadarmo(eclipse, netbeans).
  • 6. 6. 2007 11:50

    Pavel Tišnovský

    Jak jsem slíbil, tak dodávám transformační matice pro fraktální větvičku a další IFS fraktály. Formát odpovídá FractIntu, ale udělat si vlastní načítátko je vcelku jednoduché:

    my_spiral { ; by Pavel Tisnovsky
      0.8265 -0.475 0.475 0.8265 0.0 0.0 0.9
      0.1740 -0.100 0.100 0.1740 0.2 1.0 0.1
    }
    
    dragon {
      .824074 .281482 -.212346  .864198 -1.882290 -0.110607 .787473
      .088272 .520988 -.463889 -.377778  0.785360  8.095795 .212527
      }
    
    triangle1 {
      .5  0  0  .5  -0.5  0     .33
      .5  0  0  .5   0.5  0     .33
      .5  0  0  .5   0    0.86  .34
    }
    
    triangle2 {
      .5  0  0  .5  -0.5  0     .20
      .5  0  0  .5   0.5  0     .40
      .5  0  0  .5   0    0.86  .40
    }
    
    triangle3 {
      .5  0  0  .5  -0.5  0     .10
      .5  0  0  .5   0.5  0     .45
      .5  0  0  .5   0    0.86  .45
    }
    
    ctverec1  {
      .5  0  0  .5  -1  0     .25
      .5  0  0  .5   1  0     .25
      .5  0  0  .5   0  -1    .25
      .5  0  0  .5   0  1     .25
    }
    
    ctverec2  {
      .5  0  0  .5  -1  0     .10
      .5  0  0  .5   1  0     .30
      .5  0  0  .5   0  -1    .30
      .5  0  0  .5   0  1     .30
    }
    
    ctverec3  {
      .5  0  0  .5  -1  0     .04
      .5  0  0  .5   1  0     .32
      .5  0  0  .5   0  -1    .32
      .5  0  0  .5   0  1     .32
    }
    
    ctverec4  {
      .6  0  0  .6  -1  0     .25
      .6  0  0  .6   1  0     .25
      .6  0  0  .6   0  -1    .25
      .6  0  0  .6   0  1     .25
    }
    
    my_spiral2 { ; by Pavel Tisnovsky
      0.8265 -0.475 0.475 0.8265 0.0 0.0 0.40
      .5  0  0  .5  -1  0     .20
      .5  0  0  .5   1  0     .20
      .5  0  0  .5   0  1     .20
    }
    
    fern {
        0    0    0  .16 0   0 .02
       .85  .04 -.04 .85 0 1.6 .46
       .2  -.26  .23 .22 0 1.6 .03
      -.15  .28  .26 .24 0 .44 .03
      -.85 -.04 -.04 .85 0 1.6 .46
      }
    
    coral {
    0.307692 -0.531469 -0.461538 -0.293706 5.437621 8.719529 0.400000
    0.307692 -0.076923 0.153846 -0.447552 -1.289028 4.205605 0.150000
    0.000000 0.545455 0.692308 -0.195804 -4.911836 7.316535 0.450000
    }
    dragon2{
    0.824074 0.281481 -0.212346 0.864197 -1.772710 0.137795 0.771268
    -0.138580 0.283951 -0.670062 -0.279012 2.930991 7.338924 0.228732
    }
    feathe{
    0.870370 0.074074 -0.115741 0.851852 -1.278016 0.070331 0.798030
    -0.162037 -0.407407 0.495370 0.074074 6.835726 5.799174 0.201970
    }
    ferny{
    -0.160000 -0.640000 0.433846 -0.110769 5.264632 8.111285 0.321070
    0.603077 0.335385 -0.280000 0.880000 -2.757524 -0.799133 0.678930
    }
    flake {
    -0.250000 0.750000 0.250000 0.250000 -3.412025 5.797619 0.333333
    -0.250000 0.750000 0.250000 0.250000 -6.939442 2.270202 0.333333
    -0.250000 0.750000 0.250000 0.250000 0.115392 2.270202 0.333333
    }
    fossil {
    -0.017641 0.637128 0.352000 0.008000 -2.464790 8.587118 0.264315
    0.603077 0.335385 -0.280000 0.880000 -1.759852 -0.659994 0.735685
    }
    leaf{
    0.242424 -0.640152 -0.909091 -0.318182 4.613705 5.570360 0.698795
    -0.090909 -0.556818 -0.484848 0.155303 -1.103621 5.655663 0.301205
    }
    leaf2{
    0.424242 -0.651515 -0.484848 -0.344697 3.449256 2.891322 0.622449
    0.030303 -0.439394 -0.636364 -0.022727 -1.396520 6.437606 0.377551
    }
    pincher {
    0.771144 -0.484577 -0.418906 -0.724378 2.136904 7.581400 0.868575
    -0.259304 -0.109453 -0.136119 0.171144 5.871343 0.808450 0.067604
    0.308657 0.125373 0.265075 -0.073632 -5.649287 8.277147 0.063821
    }
    pull{
    0.227195 -0.466437 0.688468 0.647160 0.187642 1.466229 0.572632
    0.450947 -0.456110 0.325301 0.445783 4.939965 4.050190 0.427368
    }
    telephon {
    0.824074 0.281481 -0.212346 0.864198 -2.274768 -0.147052 0.876993
    -0.072222 0.422222 0.246296 0.059259 3.631163 7.337541 0.123007
    }
    tree1{
    0.000000 0.000000 0.000000 0.600000 0.013606 -0.454544 0.443441
    0.363636 0.581818 -0.454545 0.472727 -0.114619 3.329175 0.278280
    -0.363636 -0.581818 -0.454545 0.472727 0.141832 3.329175 0.278280
    }
    tree2{
    0.000000 0.000000 0.000000 0.600000 -0.159095 0.670061 0.445008
    0.363636 0.481818 -0.454545 0.386061 -0.908361 4.762463 0.190237
    -0.363636 -0.481818 -0.454545 0.392727 0.590171 4.708041 0.191520
    -0.545455 0.027273 0.000000 -0.600000 -0.291561 5.924281 0.173235
    }
    z{
    -0.548060 -0.181095 0.257313 -1.015920 0.818014 10.578471 0.844961
    -0.135124 -0.432836 0.147065 -0.348259 2.110459 3.261798 0.155039
    }
    
    
  • 6. 6. 2007 16:00

    patlálek (neregistrovaný)
    Dííííííííkýýýýýýýýý!!!
    Část matic už jsem připatlal do cvičného příkladu 33_1, všechny fungujou. Teď když mám možnost nahlédnout i do toho "soukolí" kde se fraktály (nejenom IFS) tvoří, tak je to teprve fascinující.