Diskuze: Pole
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 50 zpráv z 59.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
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 = new int[3]
Naplním 10,100,1000 (lze to samozřejmě cyklem, ukazuju práci s indexy)
pole[0]=10;
pole[1]=100;
pole[2]=1000;
Console.WriteLine(pole[0]) // vypíše 10
pole[0] += 10;
Console.WriteLine(pole[0]) // vypíše 20
int hodnotaTretihoPrvku = pole[3]; // chyba jsem mimo pole, správně je
int hodnotaTretihoPrvku = pole[2];
Zde tedy jasně vidíš k čemu jsou indexy. Zkus is udělat několik prográmků, začni tím, který děláš
Jasné toto chápu. Uvedu lehký příklad.
Mám
int [] pole = new int[10];
pole[0] = 1;
for (int i=0;i <10;i++)
pole[i] = i + 1;
A teď by mě zajímalo, jak to hodit celé do podmínky. Jestli to tedy jde, protože jinak bych jel třeba
if (pole[0]<10)
Console.Write("Ahoj");
Ale mě zajímá, jestli je možnost vzít všech 10 polí naplněných a
dát je do podmínky. Víš co myslím ne?
nene, dej to do for
for(int i = 0; i < 20; i++)
{
// zde si to ověř jestli ti to splňuje co má
// prvek z pole získáš pod:
// pole[i]
}
int[] pole = new int[10];
pole[0] = 1; // tento riadok nemá význam
for (int i = 0; i < 10; i++)
pole[i] = i + 1;
podmienka
for (int i =0 ; i < 10; i++)
{
if (pole[0] < 10)
Console.Write("Ahoj");
}
for (int i = 0; i < 10; i++)
{
pole[i] = i + 1;
if (pole[i] == 2)
Console.WriteLine("Je tu!");
}
Takhle jsem to cca ukázkově potřeboval. Zkrátka, aby to prohledalo všechny pole a našlo to - jako zde v příkladu, jestli tam je a udělalo akci.
pole[0] = 1;
Jinak bez tohoto to pojede též?
Nauč se správně odsazovat. Jinak to po tobě ostatní programátoři ani nebudou číst.
pole[0] = 1;
Jen na nulty index pole priradi jednicku, defaultne je tam (v C#) nula.
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.
Asi teď nechápu "Každé pole je nutné před prvním čtením
inicializovat" a poté říkáš že by se před čtením neměla číst. Jak to
myslíš ? Díky
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 )
Defaultni hodnoty datovych typu: http://msdn.microsoft.com/…s.80%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.
V c# nemusíš.
static void Main(string[] args)
{
int[] pole = new int[10];
foreach (int i in pole)
Console.WriteLine(i);
Console.ReadKey();
}
Aj bez inicializácie sa vypíšu nuly.
Aha, já jsem to pochopil trochu jinak . Tohle samozřejmě vím
Protože defaultní hodnota mi zpravidla nevyhovuje.
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
Právě mě nenapadá případ, kdy jsem potřeboval pole nul. Prakticky vždy v něm potřebuji nějaké konkrétní hodnoty.
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.
V C++ se pole inicializuje na nuly, pokud je globální nebo statické.
Platí to i pro proměnné. Jenom taková poznámka
Diky za info, ja si jen pamatuju, ze jsem v C++ obcas v poli mel nejaky
random cisla, netusil jsem, ze se to i v C++ nekdy inicializuje, dobre vedet
Díky za poklonu. Teď jsem se začetl do Haskellu a nějak se mi ten jazyk
zalíbil
Takže když je v políčku uvedena teplota "0", tak to znamená bod mrazu nebo nezměřenou hodnotu?
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.
Ted bohužel nevím o čem mluvíš ale jak říkám já sá ostatní, často
se 0 používají různě v mapách apod
O piškvorkách. Když se použije správný datový typ, tak tu "0" nepotřebuješ. Ani na trávník, o kterém psal Satik.
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.
A jaký chceš použít datový typ Navíc jak říká Satik u
pathfindingu se to ještě víc hodí. Proč si to neznázornit čísly ?
Takže grafika u her. Desktopové hry neprogramuji, proto jsem se s tím nesetkal.
Na zaznamenávání teplot je obvykle výhodnější používat databáze, které s rozlišením "0" a null nemají problém.
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...
Totéž můžeš i v těch seznamech, ale o něco efektivněji a logičtěji. Jen si to asi vezme trochu víc RAM, ale až u rozsáhlejší hry, než je obvyklé.
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?
edit: reakce na Kita
"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é.
Však se sekvenční přístup běžně používá i na těch polích. Přímý přístup se používá málokdy.
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.
Zrovna záplavový algoritmus se mi jeví sekvenční ažaž.
Zobrazeno 50 zpráv z 59.