Apropo, 3D grafika takovyho toho 3DS Max stylu je naopak plna mnoharozmernejch integralu a monte carlo integrace (a markov chains apod).

Co se grafiky tyce, tak treba jeste Computer Graphics, principles and practice - Foley, van Dam, Feiner, Hughes.
Je to starsiho data a neni to az tak programovaci, ale vysvetli to jak fungujou bspliny apod (coz je zalozeny na maticich), nurbsy apod.

Jedna z moznosti jak proniknout hloubeji do toho co je (nejenom) za nasobenim matic: http://ocw.mit.edu/courses/mathematics/18-06-linear-algebra-spring-2010/video-lectures/

XCHAOS: tedy dvě jediné abstrakce, chci říct :-)

REDGUY: ... zato když jako zdroj uvedu wikipedii, tak jsem amatér, že :-)

jako jo, s polem pointerů na objekty (indexem) se dají dělat téměř stejně pěkné věci, jako se spojovým seznam. myslím, že nejlepší protipříklad, který jsem uvedl, je vložení nového prvku poblíž začátku setříděného seznamu (a naopak u jednosměrného setříděného spojového seznamu má podobně brutální režii vložení prvku poblíž konce)

odtud se dobereme k tomu, že vyšší jazyky typu Python, které nabídnou uživatelům jednu jedinou abstrakci dynamického kontejneru (pole proměnné délky a "slovník"), asi nebudou na některé věci úplně ideální: resp. bude dobré si u nich změřit, jak rychlé je přidávání prvku na začátek vs. na konec dlouhého pole, apod.

a zejména zajímavé téma je otázka správy paměti pomocí reference counterů použitého u spojového seznamu objektů... z toho by mohl myslím být docela dobrý nový flejm :-)

XCHAOS: http://tinyurl.com/68t82bv

XCHAOS: ale nějak si mě pořád nepřesvědčil, že spojový seznam není výhodný nikdy, za žádných okolností. - to myslim uzce souvisi s tim, ze jsem se nikdy o nic podobneho nesnazil, protoze to je pitomost.

typicky jsme opět u toho, že když víš kolik toho bude, tak je pole docela výhodná struktura. - uhm. To neni pravda. Ve spouste pripadu predem vim "kolik toho bude" a presto je pole spatna struktura a naopak, ve spouste pripadu nevim kolik toho bude a pole je dobra struktura.

abstrakce kterou nabízí spojové seznamy může mít nezanedbatelné výhody - ano, muze.

XCHAOS: Ja musim do prace, ale kdyz si vygooglis OpenGL transformations, tak urcite najdes pekny vysvetleni.
Pripadne koukni do moderni pocitacove grafiky 2, tam je v zadu appendix o matice v grafice

DAVIDOWITCH: naopak... když už si zmínil to vynásobení matic, tak bych právě hrozně rád viděl nějaký kus kódu/algoritmus, který to reálně používá a je k něčemu užitečný...

REDGUY: typicky jsme opět u toho, že když víš kolik toho bude, tak je pole docela výhodná struktura. ale nějak si mě pořád nepřesvědčil, že spojový seznam není výhodný nikdy, za žádných okolností.

většina algoritmů, se kterými pracuji, se točí kolem dvou hlavní požadavků na přístup k datům: 1) nalézt prvek splňující určitá kritéria 2) procházet všechny prvky. víceméně neuvažuju tak, že bych měl datové struktury navržené tak, že vyžaduju přístup k n-tému prvku: a pokud seznam obsahuje odkaz do jiného seznamu, tak zase spíš použiju přímo pointer na prvek seznamu než index (mj. mi to umožňuje udržet integritu dat i při setřídění kteréhokoliv z těch seznamů podle libovolných kritérií).

Výkonnostní výhody polí v prostředí kdy CPU nabízí onchip cache chápu... ale současně trvám na tom, že abstrakce kterou nabízí spojové seznamy může mít nezanedbatelné výhody zvlášť pokud máme více složitějších, vzájemně provázaných datových struktur.

XCHAOS: No, tak to asi ne. V tom pripade bych to pouzil jako jasnou ilustraci toho, ze to ze nejaka vec co te v matice ucej neni okamzite a jasne patrna jeste neznamena ze to za 2-3 roky nebude superdulezitej kus pocitacovejch ved. (disclaimer: jakozto hardwarar + grafik muzu mit na tohle nestandardni nazor)

DAVIDOWITCH: kdybych tam vydržel hned po gymplu, psal by se rok 1994 (resp. 1995, kdybych býval opakoval první ročník, což se mi nechtělo ale možná bych to i dal, těžko říct). popravdě, myslíš že v roce 1994 by mě učili OpenGL? (možné to je, těžko říct)

XCHAOS: No, kdybys treba na tom FELu vydrzel do ctvrtyho semestru, byl pomerne peknej predmet o OpenGL.

XCHAOS: A uz jsme si taky vysvetlili, ze realloc se provadi pomoci prehozeni stranek pameti jen nekdy, typicky kdyz mas ty pameti fakt velky kusy. A co se rezie tyce... no, to dost zalezi na konkretnim problemu, nez aby bylo mozne rict co ma podstatne vetsi rezii, ze.

REDGUY: no... já jsem začínal s programováním v éře, kdy CPU neměly (AFAIK) prakticky žádnou onchip cache - ale naopak alokování tak velkého pole, kvůli kterému se část RAM odswapovala na disk, mohla program spolehlivě zabít a uvrhnout celý systém do mnohaminutového chroustání.

už jsem si myslím vysvětlili, že realloc() provedený pouze pomocí přehození pořadí stránek paměti pokládám za vcelku elegantní řešení. (pokud jsem realokaci pole prováděl já "ručně", tak to znamenalo kopírovat poměrně velké kusy paměti, což tedy mělo podstatně větší režii, než nějaký rozdíl mezi rychlou/pomalou pamětí)

DAVIDOWITCH: jo... asi mě někdo zapomněl naučit, jak se dělá 3D grafika pomocí násobení matic :-) (nebo jinak: ačkoliv jsem v tom věku běžně programoval v C, tak se kladl velký důraz na to, naučit mě násobit matice tužkou na papíře - ale menší důraz na to ukázat, k čemu je to dobré - pokud tenhle klub ten deficit napraví, nebudu se vůbec zlobit)