Zdravím, při svém "studiu" jsem se jaksi zasekl a nechci jet dál pokud to
opravdu nepochopím. Konkrétně se jedná o pole. Vím jak ho vytvořit, k
čemu slouží, jak vyplnit ať už pomocí cyklu "for" nebo ručně. Ale
nechápu, jak s ním pracovat. Tím mám na mysli podmínky třeba hlavně.
Zkoušel jsem to i přes metodu a prostě stále mi to píše chybu.
Jde mi třeba o toto, založím si pole, vyplním ho čísli třeba do 20ti.
A poté chci, aby mi to vypsalo, všecka čísla dělitelná dvěma. Ale jak na
to? If mi nevezme, jelikož se jedná o pole to je jasné a abych vypisovel
všech 20 polí jednotlivě a dělal jednu podmínku to je hloupé ne? Poradil
by mi někdo jak s tím pracovat a vůbec všeobecně o tom
http://www.itnetwork.cz/…utorial-pole Zde máš jasně
popsáno co a jak . Pole je
indexované, jak jsem ti říkal, každá přihrádka má svůj index,
jedinečné číslo, které identifikuje pozici v poli. Začíná se vždy od
nuly.
Pole o 3 prvcích
int[]pole = newint[3]
Naplním 10,100,1000 (lze to samozřejmě cyklem, ukazuju práci s
indexy)
Díky Misa, Zirko mě asi špatně pochopil nebo jsem se špatně vyjádřil.
Šlo/jde mi o to pracovat se všemi poli, co jsem to na rychlo zkusil tak to
jede, takže by mělo být už vše OK. Kdyžtak bych se sem zase ozval. Ještě
jednou díky, oběma.
A ještě jedna věc. Ty označuješ každý index polem. Je to jedno velké
pole s několika místy.
Když bych to přirovnal k reálnému životu. Je to vlak se sedačkami,
každá sedačka má index 0,1,2,3,4,5...... nepracuješ s vlaky, pracuješ s
jedním vlakem ale hromadou sedaček.
pole[0] ti vrátí hodnotu 0 (pro nás jako lidi prvního) indexu se kterou
normálně dál pracuješ.
Na to se nedoporučuje spoléhat. Každé pole je nutné před prvním
čtením inicializovat. I když vlastně... Vlastně se žádné pole nemusí
inicializovat, protože by se žádná definovaná hodnota neměla v programu
přepisovat a žádná by se neměla před inicializací číst.
Proc neco inicializovat dvakrat, pokud mi staci defaultni hodnota?
V C# mas zarucene, ze pole datovych typu bude po vytvoreni iniciaizovane na
defaultni hodnoty, coz je u int nula.
"If you do not initialize an array at the time of declaration, the array
members are automatically initialized to the default initial value for the array
type."
(podle http://msdn.microsoft.com/…s.71%29.aspx )
Treba v C++ se nic neinicializuje, tam proste jen dostanes kus pameti a muze
tam byt cokoliv, tam je inicializace potreba (i kdyz v DEBUG modu je int pole
tusim take vzdy inicializovane na nuly), ale C# to dela vzdy za
tebe.
Samozrejme ze pokud mi defaultni hodnota nevyhovuje, tak to jinak nez vlastni
iniciaizaci nejde, ale pokud se mi treba pole s nulami hodi, tak neni duvod
provadet druhou inicializaci
Pole nul například při tovrbě mapy, kdy se často používá
dvourozměrné pole. Například v piškvorkách může značit 0 prázdné
místo, 1 křížek hráče 1, 2 kolečko hráče 2.
Ani mě to nepřekvapuje, ty vždy programuješ jinak, než většina
"programátorů" (myslím tím teď opravdu programátory, co se tím živí),
co znám
Já pole nul občas využívám, třeba u her to může být mapa, kde nula
může být defaultní podloží (třeba tráva), kam chceš jen někde občas
vygenerovat nějaký strom apod.
Jasně, u vzoru Fly Weight to může mít své uplatnění. Jenže Fly Weight
se používá až tehdy, když nestačí kapacita paměti nebo výkon procesoru.
Tedy při optimalizaci.
Zrovna na ty teploty bych to nepouzil, tam se to moc nehodi, pokud chces
rozlisovat 0 a nezmereno.
Vyuzivam to treba spis u vlastni implementaci bitmapy (normalni bitmapa ma
pomaly pristup na pixely), defaultne jsou vsechny hodnoty 0, tedy cerna.
Take se to da vyuzit na znaceni stavu, kde treba mas 0 nezpracovano a 1
zpracovano - treba u pathfindingu muzes mit pole policek a mit tam ulozenou
hodnotu, jestli jsi to pole zpracovaval.
Někdy se hodí seznam, jindy slovník. U piškvorek by se dal použít
seznam seznamů, možná i prostý seznam. Moc jsem nad tím ještě
nepřemýšlel, ale mohlo by to být i efektivnější než matice.
Není to až moc složtiý, díky dvourozměrnému poli si znázorním ihned
pohodlně herní plochu, zároveň si udržuju kde hráči položili
(nakreslili) svoje křížky / kolečka a zároveň pohodlně můžu kontrolovat
výherní kombinace, kombinace pro umělou inteligenci apod.
Uh, nedokážu si představit, jak by mohl být seznam (nebo nedejbože
seznam seznamů) na znázornění hrací plochy pro piškvorky efektivnější
než obyčejné pole, přijde mi to jako používat na vrtání zubů vrták na
studny...
Kde jsou seznamy, tam nemusíš počítat indexy do pole. Nemusíš ani
procházet neobsazená políčka.
Kromě toho se takové seznamy obvykle interně zpracovávají jako pole
přes pointery. Takže seznamy mohou být efektivnější než pole. Hlavně si
ale pod tím mým seznamem seznamů nepředstavuj nějaký čtverec. Ten jsem
opravdu na mysli neměl.
Já i na herní plochu až 1000x1000 vezmu klasické dvourozměrné pole,
nevím jestli už to není moc ale funguje to velmi dobře. Přijde mi prostě
nesmysl dělat si nějaké seznamy seznamů na pouhé zobrazení a udržení 2D
hrací plochy
Já i na herní plochu až 100x100 vezmu klasické dvourozměrné pole,
nevím jestli už to není moc ale funguje to velmi dobře. Přijde mi prostě
nesmysl dělat si nějaké seznamy seznamů na pouhé zobrazení a udržení 2D
hrací plochy
Aha, až teď mi došlo, jak jsi to myslel - zaznamenávat do toho seznamu ty
jednotlivé tahy (třeba něco jako List<Tah>, kde tah by značil
pozici a symbol).
Pro malé množství tahů by to bylo efektivnější to zpracovávat takhle,
ale pro velké množství tahů by to bylo výrazně pomalejší, asi bych dal
přednost tomu "stabilnějšímu" řešení, které bude trvat vždy stejně
dlouho - tedy dvourozměrné pole stavů, kde indexy do pole jsou indexy do
hrací plochy.
"Kde jsou seznamy, tam nemusíš počítat indexy do pole.
...
Kromě toho se takové seznamy obvykle interně zpracovávají jako pole přes
pointery. Takže seznamy mohou být efektivnější než pole."
I když ty indexy do pole u seznamu nepočítáš, tak se to stále za tebe
musí interně provést i u toho listu.
Když na stejnou věc (při které nebudeš měnit velikost kolekce)
použiješ pole a seznam, vždy vyhraje pole.
Já teda nevím. Já žil v přesvědčení, že seznam se hodí na
sekvenční
přístup a pole na okamžitý přístup k libovolné položce. Zbavovat se
jednoho systému na úkor druhého je snad zbytečné, ne?
"hrací plocha" je vlastně jakýmsi synonymem pro "pole". Nevidím důvod,
proč bych v opodstatněných případech nepoužil pole. Jen mám občas pocit,
že se někdy používá pole i tam, kde by se měly použít jiné datové
typy.
Například Fortranu nic jiného než pole vlastně ani není, pracuje s
polem efektivněji než C a hlavně se mnohem lépe programuje. V jazycích
odvozených od C by se měly používat vyšší datové struktury všude tam,
kde je to vhodné.
Ve hrách se přímý přístup používá docela často, viz třeba nějaký
ten pathfinding s záplavovým algoritmem, kde skáčeš do pole všelijak, jen
ne sekvenčně.
Pochopil jsi to správně s tím jedním seznamem. Ten tah však můžeš
zaznamenat do více seznamů s takovou redundancí, aby vyhledávání např.
výherních pozic nebo podklady pro AI bylo efektivnější.
Vedlejším efektem by bylo, že hrací plocha se stane de facto neomezeně
velkou, což třeba u piškvorek asi nebude zrovna nejžádanější
vlastnost.
Mě se záplavový algoritmus sekvenční nejeví vůbec, začínáš přeci
na poli, odkud chceš hedat a pak procházíš postupně okolní body, kde tam
je něco sekvenčního?
Např. když máš pole
0 1 2 3
4 5 6 7
8 9 A B
C D E F
a hledal bys cestu z 0 do A, tak budeš postupně prohledávat body (přesný
postup by záležel na implementaci, jedna z nich by dopadla takto)
1 4 2 5 8 3 6 9 C 7 A
Uh.
To klidně můžou, ale to ten záplavový algoritmus přece vůbec nezajímá,
on prohledává okolí ve "vlnách", viz animace (nutno kliknout, aby se to
animovalo).
Pod sekvenčním přístupem si představuju třeba foreach na prvcích pole,
ale ne to, že při přímém přístupu do pole jde náhodou pár indexů za
sebou.
Pokud s polem pracuješ cyklem foreach, tak s ním pracuješ jako se
seznamem.
Ty indexy však nemusí jít za sebou. Zaplavuješ všemi směry, proto z
každého prvku vedou 4 cesty na sousední prvky. Je to vlastně neorientovaný
graf, který však nemusí být omezen na 4 cesty, ale třeba u piškvorek
může mít 8 cest z každého prvku.
Tohle jsou však algoritmy, které nejsou příliš výhodné v
imperativních jazycích, ale např. v Lispu se používají velmi často.
Hezkým příkladem by mohlo být testování korektnosti sudoku. Můžeš to
udělat jako matici 9×9 a udělat 3 algoritmy na test (vodorovně, svisle,
skupina). Když to však uděláš jako 81 objektů, které umístíš do 27
seznamů po 9 objektech, stačí ti jen jeden testovací algoritmus na
všechno.
"Pokud s polem pracuješ cyklem foreach, tak s ním pracuješ jako se
seznamem."
Někdy také, ale byl to jen příklad toho, co si představuju pod pojmem
sekvenční přístup.
"Ty indexy však nemusí jít za sebou. Zaplavuješ všemi směry, proto z
každého prvku vedou 4 cesty na sousední prvky. Je to vlastně neorientovaný
graf, který však nemusí být omezen na 4 cesty, ale třeba u piškvorek
může mít 8 cest z každého prvku."
Jestli prohledáváš osmiokolí nebo čtyřokolí je v tomhle případě
úplně jedno.
To už přece není sekvenční přístup, když ty indexy nejsou za sebou, ale
skáčeš při prohledávání v podstatě na náhodné indexy do té
mapy...
"Tohle jsou však algoritmy, které nejsou příliš výhodné v
imperativních jazycích, ale např. v Lispu se používají velmi často."
Nevím, proč by neměl tenhle algoritmus být výhodný v imperativním jazyce.
Lisp neznám, nevidím moc důvod tyhle obskurní jazyky používat .
U toho sudoku souhlasím, že by to tvé řešení bylo docela hezké.
Já nekritizuju seznamy, jen mi to přišlo, že bys je nejraději cpal
všude, i tam, kde se více hodí pole, třeba na tu reprezentaci mapy pro
záplavové hledání.
Ani když tu mapu máš místo pole uloženou jako seznam, tak tam
nezapisuješ/nečteš sekvenčně při záplavovém prohledávání, vždyť je
to nesmysl, ještě jednou:
Mám mapu
0 1 2 3
4 5 6 7
8 9 A B
C D E F
uloženou jako list (0 1 2 3 4 5 6 7 8 9 A B C D E F)
a hledám tu cestu třeba z 0 do A, tak saháš postupně na indexy
1 4 2 5 8 3 6 9 C 7 A
Já tam pořád žádnou sekvenci nevidím a jako sekvenční přístup mi to
rozhodně nepřipadá
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.