Új hozzászólás Aktív témák
-
Jhonny06
veterán
válasz atti1848 #3200 üzenetére
Dobhat, mert gyakorlatilag az idő függvényében generálódnak a számok, így minél kisebb az értéktartomány, annál valószínűbb, hogy lesz több ugyanolyan elem is. Ha késleltetés nélkül fut, akkor meg pláne, hiszen nincs idő nagyobb tartományban generálni, ezért érdemes.
Viszont a késleltetés megtétele után még mindig ott van a Te megoldásod, miszerint ellenőrizheted, hogy nincs-e két ugyanolyan érték a tömbben, egy egymásba ágyazott for ciklussal. Azért ajánlottam előbb a késleltetést, mert ha kicsi az értéktartomány és kvázi majdnem mindig hasonló értéket generál a kód, akkor szépen "végtelen" (persze nem teljesen) ciklus jön létre, mert ugye kap a tömb egy számot és összehasonlítja az következővel, ami ugyanaz, meg újra ugyanaz, stb. és csak akkor csinál valamit, ha a két szám nem egyezik meg, tehát ezzel nem árt vigyázni.
Szóval az a legjobb megoldás, ha először ellenőrzöd, hogy nincs-e benne már, majd generálsz és késleltetsz.
for (int i = 0; i < szamok.Length; i++)
{
for(int j = 0; j < szamok.Length; j++)
{
if(szamok[i] != szamok[j])
{
szamok[i] = rnd.Next(1, 90);
Thread.Sleep(100);
}
}
}[ Szerkesztve ]
-
Jhonny06
veterán
válasz WonderCSabo #3202 üzenetére
Ilyeneket nem tudok, sorry.
-
Jhonny06
veterán
válasz WonderCSabo #3204 üzenetére
Ez a HashSet kvázi a C++-os vector ekvivalense?
-
WonderCSabo
félisten
válasz Jhonny06 #3205 üzenetére
Nem, egyáltalán nem. Az STL vector egy sima tömb, csak van rá húzva egy pár fv, növeli a méretét, hogy ha kell, stb. A HashSet pedig egy hashtáblán alapuló adatszerkezet. És amiért jó nekünk ide a hashtábla:
- nem lehet duplikált kulcsokat belerakni
- a berakás (az esetek nagy részében), és a többi alapművelet mindig (persze ezek most nem is kellenek) konstans komplexitásúTermészetesen az STL vectorra egyik sem igaz (kivéve a berakást), hisz az csak egy tömb. Ami miatt viszont gondot okozhat a hashtábla, az az, hogy az elemek semmilyen sorrendiséget nem fognak megtartani (tehát se a kulcsok rendezése alapján, se a berakás szerint), de jelenleg ez sem probléma.
[ Szerkesztve ]
-
Jester01
veterán
Mellesleg általában tilos ilyen módon generálni a véletlenszámokat mivel nem determinisztikus hány random hívás lesz. A helyes megoldás mindig csak a maradék számok közül választani, hiszen valójában is ez történik.
Jester
-
WonderCSabo
félisten
válasz Jester01 #3207 üzenetére
Ez természetesen így van, de 10 db (vagy sokkal több) szám esetén 1-hez nagyon közeli valószínűséggel nagyon rövid idő alatt fut le. Én tesztelgettem ezt, és még sosem sikerült elhúzni az időt ezzel. Persze ha biztosra akarsz menni, akkor csinálsz egy láncolt listát 1-n-ig, megkevered őket, aztán random indexeket választasz és a választottad kiszeded a listából, csinálod ezt amíg üres nem lesz a lista.
[ Szerkesztve ]
-
nagyúr
válasz WonderCSabo #3202 üzenetére
A HashSet-ben nem lehet duplikált elem, ha jól tudom, ez viszont ezt nem garantálja. Én inkább egy sima generikus listában tárolnék.
[ Szerkesztve ]
-
nagyúr
válasz WonderCSabo #3210 üzenetére
Közben rátaláltam az MSDN-en:
"A set is a collection that contains no duplicate elements, and whose elements are in no particular order."
Vagyis valahogy még azt is ki kell ötölni, hogyan kerüljük el a duplikálást, különben hibát kapsz. Nem használtam még HashSet-et csak egyszer kipróbáltam, de nem látom az előnyét sajnos. Veszek inkább egy generikus listát és abban is bármit meg tudok oldani.
Ja, most látom, hogy a duplikálás kikerülésére trükköztetek pár hsz-en keresztül. sosem használok randomot, erzért ez nem is foglalkoztat, de akkor már inkább vizsgálnám, hogy van-e már ilyen a kollekcióban. Ha nem kell millió rekordot disctinct módon randomolni, akkor nem lesz a teljesítmény se gond
[ Szerkesztve ]
-
WonderCSabo
félisten
Te most vmit nagyon elnézel... És még idézted is azt, hogy
A set is a collection that contains no duplicate elements
Tehát: nem lehetnek benne duplikált kulcsok. Pont ezt használtam ki ennél a kis kódnál. A hashtábláknak pedig óriási előnyei vannak más adatszerkezetekkel szemben, egy kis ízelítőért lásd előző hszemet...
Szerk.: Ja látom már kiderült a dolog.
Szabesz: Az if is feleslegs, az csak azért van ott, hogy dupkilálás esetén várjon picit a progi, de teljesen felesleges várni.
stevve: de akkor már inkább vizsgálnám, hogy van-e már ilyen a kollekcióban
Ez az amit a hashtábla konstans idő alatt tesz meg a hozzáadással, Te pedig minden egyes új szám hozzáadásánál lineáris keresést végeznél...
[ Szerkesztve ]
-
nagyúr
válasz WonderCSabo #3214 üzenetére
Igen, már látom, mit néztem be.
Viszont a hashtáblák előnyét nem látom. Kb. egyszer találkoztam olyan rendszerrel, ahol ilyenekkel kellett játszani és kínszenvedés volt (.net 2-es kód). Tudsz példákat mondani a generikusok ellenében?
"Ez az amit a hashtábla konstans idő alatt tesz meg a hozzáadással, Te pedig minden egyes új szám hozzáadásánál lineáris keresést végeznél..."
És erre írtam, hogy ha nem kell milliónyi különböző érték, nem fáj.
Ez a HashSet<T> már egy viszonylag használható dolognak tűnik az eddigi megoldásokhoz képest. Lehet, hogy majd ki is próbálom jobban.
[ Szerkesztve ]
-
WonderCSabo
félisten
A hashtábla is generikus.
Már leírtam az előnyeit. Konstans idejű hozzáadás (majdnem mindig), eltávolítás és lekérés, asszem ezek önmagukban bőven elegendő érvek.
Szerk.: A második részre: a kód is sokkal tisztább vele, plusz miért ne oldhatnánk meg elegánsabban a dolgot, ha már van mód rá. Én csak beposztoltam a kódot, hogy ezt megmutassam. Meg amúgy is ezek a kis programok csak példák, a való életben nem 10 elemű listákkal fog csak foglalkozni a tanuló.
(#3217) Szabesz: Okés.
[ Szerkesztve ]
-
őstag
válasz WonderCSabo #3214 üzenetére
Tisztában vagyok vele. Csak a miértekre próbáltam rámutatni.
¯\_(ツ)_/¯
-
nagyúr
válasz WonderCSabo #3216 üzenetére
Ez a HashSet generikus, de a hashtábla (HashTable) más.
"Meg amúgy is ezek a kis programok csak példák, a való életben nem 10 elemű listákkal fog csak foglalkozni a tanuló."
A példa jó is volt, én nem olvastam át elég jól elsőre.
Egyébként nyilván könnyebb hash alapján elérni valamit (int) ebben igazad van.
[ Szerkesztve ]
-
WonderCSabo
félisten
Elírtam, úgy értettem, hogy a HashSet is az, a HashTable osztály valóban nem az. A többinél pedig direkt magyarul kisbetűvel írtam, mert általánosságban beszéltem a hashtáblálról, nem a HashTable osztályról.
Mellesleg természetesen a HashTable annyival tud többet a HashSetnél, hogy az előbbi kulcs-érték párokat tárol, az utóbbi csak kulcsokat. De HashTable helyett akkor inkább Dictionary.
[ Szerkesztve ]
-
nagyúr
válasz WonderCSabo #3219 üzenetére
Ja, értem.
-
nyxor
aktív tag
Üdv!
Fősulin olyan beadandó feladatot kaptam, ami egy .cs forrásállományból készít html dokumentációt. Annyi a lényeg, hogy legyen egy táblázat, aminek felül 2, alul 1 cellája van. A bal felsőben sorakozzanak az osztályok nevei abc sorrendben linkként, a jobb felsőben a kiválasztott osztály adattagjai, metódusai, eseményei szintén linkként, a lenti cellában pedig a bal felsőben kiválasztott elem adatai jelenjenek meg, beleértve a hívó és a meghívott metódusokat. Mindezt egy szép UI-val megfejelve.
Odáig eljutottam, hogy kész a program kezelőfelülete, lehet fájlt nyitni, kimeneti állomány helyét tallózni. A bemeneti fájlt szépen be is olvassa (File.ReadAllLines-t használtam), aztán a sorokon végighaladva meghatározza a kapcsos zárójelek alapján a szintet a kódban, ami szerint eldönti, hogy osztályról vagy metódusról van-e szó. Ez eddig működőképes is, leteszteltem és gyönyörűen összegyűjt minden adatot. A kérdésem már csak az, hogyan lehetne hatékonyan eltárolni ezeket az adatokat, hogy ne keveredjenek össze a metódusok és a leírásaik (valahogy hozzárendelni)? Struktúra kéne neki? És hogy utána gond nélkül lehessen rájuk hivatkozni a html oldalakon belül. A legfontosabb pedig: hogy a francba írjak html-t C# kódból? xml-t tudok, de pont nem az kell. Külső kód pedig nem használható, csak saját és MS által írt kód.
Bocsi hogy ilyen hosszúra sikerült, a válaszokat előre is köszönömLG G2
-
-
WonderCSabo
félisten
válasz martonx #3223 üzenetére
Sztem a kérdés arra vonatkozott, hogy hogyan lehet generáltatni.
[ Szerkesztve ]
-
drkbl
őstag
A másik oldalról megközelítve: When to Use Generic Collections
-
nagyúr
Köszi, azt tudom, mikor használjak generikusokat - nagyjából mindig az én esetemben . tegnap kicsit benéztem, ezért próbálgattam is a HashSetet. Ahogy látom, ha ömlesztve van egy csomó adatom (mondjuk milliós nagyságrendben néztem) és nem érdekel a rendezhetőség, csak ki-be akarok olvasni és gyorsan elérni, akkor jó és tényleg gyors, de egyébként IList, ha rendezett kell és ha úgyis iterálni kell. Az, hogy a hash alapján gyorsabb keresni, nem is annyira lényeges, inkább az, hogyan kellenek az adatok.
[ Szerkesztve ]
-
fabal_
csendes tag
Sziasztok!
A következő problémám lenne. A main formból nyitok egy formot szálkezeléssel(ThreadPool-al). Itt megtudok adni fhszn-i adatokat és képeket feltölteni(new thread-el stat módban). Ami ekkor egy központi helyre másolódik s elérési út egy mysql adatbázisba és megjelenik egy pictureboxxon. A Gondom az hogy a képeket amiket betöltöttem(background worker-el) elkezdem törölni. Vagyis törlöm mysql-böl a List<Image>-et újra beolvasom a tölendő elem nélkül. S ezután akarom törölni a file-t Ekkor elkezd sírni h egy másik szál jelenleg használja a törlendő képet. A neten találtam eme kódot erre a parára de nem használ. Itt a PICS[] a képek elérési útjának a tömbje lenne.
for (int i = 0; i < Pics.Length - 1; i++)
{
Image node = Image.FromFile(Pics[i]);
int[] points = Picturebox_Resize(91.0, 91.0, node.Width, node.Height);
var img = Image.FromFile(Pics[i]).GetThumbnailImage(points[0],points[1], null, new IntPtr());
node = img;
img = null;
}
Találkoztatok már efféle dologgal? Van valami ötletetek rá hogy lehetne megoldani?
Üdv fabaluff a hegyeken túl s innen ahol nap szeli át a zöldet csendben s szépen.
-
drkbl
őstag
Nem igazi válasz, inkább csak ismereteim összefoglalása
Pontosan A generikusok legnagyobb előnye a boxing/unboxing [1][2] elkerülése.
A hash, mint a linkelt cikk írja, arra jó, hogy komplex kulcsot rövidít. Pl. tárolni kell 1000 nagyságrendű embert, kulcs név+születés helye+születés ideje+anyja neve, akkor megfelelő, az adott tartományban ismétlődést nem adó hash függvénnyel memória spórolható, és/vagy a keresés nagyban gyorsítható. Pl. egy adatrögzítő View saját magán belül ellenőrizheti a véletlen ismétlődést.
A hash függvény viszont adhatja ugyanazt az eredményt különböző kulcsokra, ezért kezelni kell a hash ütközést (amúgy nem túl régen kénytelenek voltak kiadni egy biztonsági frissítést az ütközéskezelés időigénye DoS lehetőség miatt a keretrendszerhez). A HashTable és a Dictionary más-más módszert használ erre, ez is lehet szempont a választáshoz.
-
drkbl
őstag
Utánanézve, ajánlott a Dispose használata a nem menedzselt erőforrások felszabadításához: Image.Dispose Method
Cleaning Up Unmanaged Resources
Kérdés továbbá, hogy GetThumbnailImage új képet ad vissza, vagy hivatkozik az eredetire, mert amíg hivatkozik, nem szabadul fel a hivatkozás miatt.
-
amargo
addikt
"Viszont a hashtáblák előnyét nem látom."
"És erre írtam, hogy ha nem kell milliónyi különböző érték, nem fáj."
Nem csak millió, már kevesebbnél is bizonyít.A legegyszerűbb példa, hogy sokkal gyorsabb ez a belső szerkezetének köszönhető. Nyilván valamit valamiért alapon megy ez is, mivel karban kell tartani a index-et. Képzeld el úgy, mint egy adatbázis táblát, amire index-et raksz.
Egy példa:
Adott egy kritikus adatkiszolgáló szál - amint más szálak tartanak karban -, ha adat kell belőle, akkor azt gyorsan kell publikálni. Itt az IList rettentő csúnyán elvérez.Amint látom más példákat is felhoztak rá.
“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
WonderCSabo
félisten
Nyilván valamit valamiért alapon megy ez is, mivel karban kell tartani a index-et.
Nem, nem kell karbantartani semmiféle indexet. Az elem címe lekéréskor, hozzáadáskor, törléskor is a kulcs alapján a hash fv-el képződik le, ez O(1) - es művelet. Itt hozzáadáskor lehet csak egy kis probléma: ha kezd betelni a hashtábla, akkor nagyobbat kell lefoglalni, és átmásolni az elemeket. Ha pedig a hash fv már meglévő elem indexét képezi, akkor ezt az ütközést fel kell oldani. A HashTable ezt újrahasheléssel oldja meg, a Dictionary pedig láncolással. Vagy erre értetted az index karbantartását?
-
amargo
addikt
válasz WonderCSabo #3233 üzenetére
"Vagy erre értetted az index karbantartását?"
Igen. Jobban oda kell figyelni a használatára.“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
Chipi333
csendes tag
Ahogy látom, ha ömlesztve van egy csomó adatom (mondjuk milliós nagyságrendben néztem) és nem érdekel a rendezhetőség, csak ki-be akarok olvasni és gyorsan elérni, akkor jó és tényleg gyors, de egyébként IList, ha rendezett kell és ha úgyis iterálni kell.
Most C# konkrétumot nem tudok mondai, de ha rendezettség és gyors random elérés is kell, arra vannak olyan adatszerkezetek amik egy rendezett struktúrában tárolják az adatokat (pl vmilyen fa), és emellett tartanak egy hash táblát is hozzá. Javában biztosan van ilyen, és hát gondolom a .net frameworkből sem maradt ki
-
fabal_
csendes tag
Sikerült megoldani. A gond ott volt h mikor listába fűztem fel a képeket s törlésnél a törölni kívánt képek nélkül újra totlama listát. A törölni akarrt elemek benn maradtak a memóriában.(80-100 db kép esetén (2-4 megás) nem tudom hogy de 1,5 GB memóriát megettek, ne kérdzzétek hogyan.) Mikor beviszem a rendszerbe a képeket egy thumbnail méretű kis képet hozok létre ami kb pár KB így nics nam memória használat. Mikor törlöm a képet akkor adatb-ból a hivatkozást s a meghajtóról peedig az ereeti angy képet törlöm a thumbnail megmarad. Mikor legközelebb megnyitom ezt a formotellenőrzöm a File.Exist() témát s ha nincs meg a fájl akkor törlöm a thumbnail-t is.
Mikor készítem a thu,mbnail képeket erősen ráhívom a GC-t így GC.Collect(GC.GetGeneration(this), GCCollectionMode.Forced);
//GCCollectionMode.Forced;
GC.WaitForPendingFinalizers();
A dispose-os témát nézegettem. De simán csak ráhívtam. Override-ot nem csináltam mivel annyira nem vágom a működését jelenleg.uff a hegyeken túl s innen ahol nap szeli át a zöldet csendben s szépen.
-
shaggy
aktív tag
Sziasztok!
Nekem az lenne a kérdésem hogy lehetne a már létező progit ami access adatbázisban titkositottan tárolja az adatokat átírni hogy XML-be tárolja?
Kezdő vagyok még nagyon nehéz megszokni nekem ezt a c#-ot.
Előre is köszönöm a segítséget.
-
trisztan94
őstag
Sziasztok!
1-2 hónapja tanulgatom a C#-ot, jelenleg egy memóriajátékot akarok írni, de valamit nem tudok, és sehogy sem tudok rájönni. A program lényege, (gondolom mindenki tudja, hogy mi egy memóriajáték, de azért leírom ) hogy van egy 4x4-es panelem feltöltve gombokkal, amik feketék alaphelyzetben. Rákattintasz, fehér lesz és kidob egy számot. Eddig minden klafa, tök jól működik, viszont elakadtam ott, hogy leellenőrizze a program, hogy ha a második kattintással felhozott gomb értéke nem egyezik az előzővel, akkor állítsa vissza feketére, ha egyezik, akkor meg maradjon úgy. Több órája ezzel sz@rakodok, sehogy sem tudok rájönni.Itt a kód:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace Memória
{
public partial class Form1 : Form
{
int lepesek = 0;
int talalatok = 0;
Button[] gombok = new Button[16];
Random r = new Random();
int elsogomb;
public Form1()
{
InitializeComponent();
}
private void but_new_Click(object sender, EventArgs e)
{
for (int i = 0; i < 16; i++)
{
gombok[i] = new Button();
gombok[i].Parent = panel;
gombok[i].Width = panel.Width / 4;
gombok[i].Height = panel.Height / 4;
gombok[i].Left = (i % 4) * (panel.Width / 4);
gombok[i].Top = (i / 4) * (panel.Height / 4);
gombok[i].BackColor = Color.Black;
gombok[i].Click += gombertek;
}
for (int i = 0; i < 8; i++)
{
for (int j = 0; j < 2; j++)
{
bool lerakva = false;
while(!lerakva)
{
int mivanmi = r.Next(0,16);
if (gombok[mivanmi].Tag==null)
{
lerakva = true;
gombok[mivanmi].Tag = i+1;
}
}
}
}
}
void gombertek(object sender, EventArgs e)
{
(sender as Button).Text = (sender as Button).Tag.ToString();
(sender as Button).Enabled = false;
(sender as Button).BackColor = Color.White;
elsogomb = int.Parse((sender as Button).Text);
}
void ugyanaz(object sender, EventArgs e)
{
}
private void but_exit_Click(object sender, EventArgs e)
{
this.Close();
}
}
}Köszönöm előre is
https://heureka-kreativ.hu
-
fatal`
titán
válasz trisztan94 #3239 üzenetére
Én ezt úgy csináltam, hogy egy tömbbe beraktam a felforgatott gomb indexét (esetedben akár magát a számot is rakhatod) és a második gombnál ezt hasonlítottam össze. Ha nem egyeznek akkor visszaállítod őket feketére, ha egyeznek úgy hagyod.
-
trisztan94
őstag
Hát ezt én is így logikáztam ki, de a kódot nem tudom megírni
Edit:
Eddig erre jutottam:
void gombertek(object sender, EventArgs e)
{
(sender as Button).Text = (sender as Button).Tag.ToString();
(sender as Button).Enabled = false;
(sender as Button).BackColor = Color.White;
for (int i = 0; i < 2;i++ )
{
felforgatott[i] = int.Parse((sender as Button).Text);
if (felforgatott[i] != int.Parse((sender as Button).Text))
{
(sender as Button).BackColor = Color.Black;
}
else
{
(sender as Button).BackColor = Color.White;
}
}
}[ Szerkesztve ]
https://heureka-kreativ.hu
-
Jester01
veterán
válasz trisztan94 #3241 üzenetére
Nagyon egyszerű, vezess be egy member változót ami a legutoljára felfordított indexet tárolja, illetve azt is, hogy érvényes-e. Legyen mondjuk -1 ha nincs ilyen (vagyis "első gomb" következik). Induláskor ezt akkor -1. A gomb kattintás eseménykezelőjében akkor megnézed, hogy ez -1 vagy sem. Ha az, akkor ez most "első gomb", egyszerűen elteszed az aktuális indexet ebbe a változóba és kész. Ha nem -1, akkor benne van az előzőleg felfordított gomb indexe. Ez alapján már össze tudod hasonlítani, és nem egyezés esetén azt és az aktuális gombot is visszafordítod (és persze az enabled-et is visszaállítod). A segédváltozót pedig -1-re teszed, mivel a következő gomb megint "első gomb" lesz. Leírva bonyolultabb mint leprogramozni
[ Szerkesztve ]
Jester
-
WonderCSabo
félisten
válasz trisztan94 #3241 üzenetére
Nem is értem miért kell ezt ennyire túlbonyolítani. Egyszerűen egy db int-ben tárolod elsőnek felforgatott gomb indexét. Ha gombok[lastIndex].Text == sender.Text, akkor mindkettőt fehérre állítod. Minden második kattintás után meg mondjuk a lastIndex-et -1 -re állíthatod, ezzel tudod magadnak jelezni, hogy még nem kattintottak először.
A magyar elnevezéseket, főleg az ékezetes elnevezéseket nagyon messziről kerüld el.
Bazzeg nem igaz, hogy Jester leírta már ugyanezt előttem.
[ Szerkesztve ]
-
trisztan94
őstag
-
kingabo
őstag
válasz WonderCSabo #3243 üzenetére
Ebben az esetben nem ért egy + védelem, hogy 2* kattintott-e ugyanarra, mert a feltételed akkor is teljesül.
-
n00n
őstag
Van egy ListBox-om (Visual C#) amibe x db nevet töltök. Van kettő gombom, az egyik ABC sorrendbe állítja (ListBox_neve.Sorted = true) a neveket, a másik hatására rendezetlené kellene válnia. Viszont a rendezetlenséget hogyan lehet megoldani? A ListBox_neve.Sorted = false nem működik. Ötlet?
-
ArchElf
addikt
Tárold el az eredeti sorrendet valahol (pl a Tag property-ben) és rendezz aszerint. A ListBox-nak nincs "eredeti" sorrendje, mindig csak az aktuális van.
A Sorted property amúgy arra jó, hogy nem csak sorbarakja a listát, de az ]j elemeket is sorreendbe rakva adja hozzá.AE
[ Szerkesztve ]
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest