BGAFC Vendégkönyv

Σ: 16 post

saxus (statz)

#9, Agyfasz (419)

264 | #1c70 | ^ | Idézet | Wed, 09 May 2012 00:53:50 +02

84.3.*.*

*.catv.pool.telekom.hu

saxus írta/wrote:
Inkabb tömbindexnek használd, aztán isset(). Szerintem.

Vagy mondok mégjobbat: hányd be az egészet egy tömbbe, rendezd, aztán szaladj végig rajta. Ki fog jönni a duplikáció, mikor azonos elem következik.

TCH (statz)

#1, Főfasz (10443)

526 | #1c71 | ^ | Idézet | Wed, 09 May 2012 12:30:40 +02

46.107.*.*

*.catv.pool.telekom.hu

saxus írta/wrote:
Toolok jók hozzá és teszi a dolgát. Mi kell még? :)

Passz, nem próbáltam, nem nyilatkozom.

saxus írta/wrote:
Vagy mondok mégjobbat: hányd be az egészet egy tömbbe, rendezd, aztán szaladj végig rajta. Ki fog jönni a duplikáció, mikor azonos elem következik.

Ez nem rossz ötlet, csak annyi memória a világon nincs. 1024 bites a hash, és pontosan 2^32 lenne belőle, ez pedig 512 giga. Meg aztán a rendezés, mikorra futna le rajta?

saxus (statz)

#9, Agyfasz (419)

906 | #1c72 | ^ | Idézet | Wed, 09 May 2012 15:43:38 +02

0.0.*.*

*.kgb.gov.su

TCH írta/wrote:
Ez nem rossz ötlet, csak annyi memória a világon nincs. 1024 bites a hash, és pontosan 2^32 lenne belőle, ez pedig 512 giga. Meg aztán a rendezés, mikorra futna le rajta?

Ahahah, jelszot torsz? Kezdhetsz gyukteni Tesla kartyakra. :) Mondjuk, ha 1024 bites, akkor 2^1024 db letezik belole.

Egyaltalan hol taroslz 512G-t? Masreszt meg normalisabb 2 utas szerverlapba siman belemegy 768G memoria manapsag, igaz, a 32G-s RegECC modulok onmagukban szerintem onmagukban dragabbak, mint az alaplap.

Egyebkent, ha ennyi hashed van, meg mindig tudod particionalni oket. Szetparticionalod mondjuk 256 db-ra a legfelso byte alapjan, maris csak 2 giga, ami total kenyelmesen kezelheto meg a legocskabb desktop gepen is. Eleg sokaig particionalod, meg egy C64 clusterrel is megcsinalod.

De amugy 1024 bites kulcsot te nem fogsz egykonnyen megtorni otthon.

saxus (statz)

#9, Agyfasz (419)

195 | #1c73 | ^ | Idézet | Wed, 09 May 2012 15:45:07 +02

0.0.*.*

*.kgb.gov.su

TCH írta/wrote:
Meg aztán a rendezés, mikorra futna le rajta?

Mellesleg, meg mindig joooooval hamarabb lefut egy O(N*logN) rendezes ra, mint egy O(N^2).

saxus (statz)

#9, Agyfasz (419)

204 | #1c74 | ^ | Idézet | Wed, 09 May 2012 15:49:13 +02

0.0.*.*

*.kgb.gov.su

Sot, tovabbi otletek: tombositett adatok helyett en szetparticionalnam kis darabokra, fastrukturaban. Ekkor nem kell az egesz kulcsot tarolni, csak a veget, amely nagyon sokmindent jelentosen egyszerusit.

saxus (statz)

#9, Agyfasz (419)

1228 | #1c75 | ^ | Idézet | Wed, 09 May 2012 16:06:19 +02

0.0.*.*

*.kgb.gov.su

Jo, semmi felreertettem, nem a teljes kulcsteret akarod letarolni, hanem csak egy kis reszet. Na akkor ezt marhagyorsan le tudod particionalni kis reszekre. Utana a kis reszeken mar gyors rendezni.

Masik megkozelites, hogy fakra bontod. Pl. lebontod 8-16 bites reszekre, ennek megfeloen lesz 128/64 szinted. A fa adott levelen azt tarolod, hogy milyen reszekbol van gyermekelem. Amikor keresel elkezded olvasni a bitsorozatod valamelyik iranybol (gyakorlatilag mindegy a sorrend is, lenyeg, h ugyanaz legyen minden kulcson :).

Elonye, hogy marha gyorsan ki fog jonni, hogy van-e foleg ekkora kulonbsegek. Hatranya, hogy macerasabb a fat felepiteni, karbantartani (leveleket celszeru sorba rendezni, ott logkert alkalmazni, ha sok van. bar ott is lehet optimalizalni. nehany elemnel nem fog kijoni a logker elonye egy sima linearis kereseshez kepest.

Lehet meg azzal is trukkozni, hogy mondjuk nem fix, hanem dinamikus meretu leveleket hasznalsz, pl. 8-16-32 bites darabokat. Elonye, hogy nem fogja annyira elaprozni az also szinteket (hiszen ott valoszinuleg ugy is csak 1-1 lancolt listaba fog fajulni a dolog), a felso reszek meg kis 8 bitesre fognak darabolodni szukseg eseten, ami gyors szetvalasztast fog eredenyezni.

TCH (statz)

#1, Főfasz (10443)

1760 | #1c76 | ^ | Idézet | Wed, 09 May 2012 16:19:55 +02

46.107.*.*

*.catv.pool.telekom.hu

saxus írta/wrote:
Ahahah, jelszot torsz? Kezdhetsz gyukteni Tesla kartyakra. :) Mondjuk, ha 1024 bites, akkor 2^1024 db letezik belole.

Nem a picsába! Nem török jelszót, én írtam egy 1024 bites hash algoritmust és tesztelni szeretném!

saxus írta/wrote:
Egyaltalan hol taroslz 512G-t?

Erről beszéltem, hogy sehol! Ezért keresek valami módszert amivel tudnám tesztelni az algoritmusomat, hogy van-e a sorozatban egyezés, előfordulhat-e, hogy 0 és 2^32 közötti számokra ad-e kétszer ugyanazt. Aztán ugyanezt stringekre.

saxus írta/wrote:
Masreszt meg normalisabb 2 utas szerverlapba siman belemegy 768G memoria manapsag, igaz, a 32G-s RegECC modulok onmagukban szerintem onmagukban dragabbak, mint az alaplap.

Biztos van ám ennyi pénzem...

saxus írta/wrote:
Egyebkent, ha ennyi hashed van, meg mindig tudod particionalni oket. Szetparticionalod mondjuk 256 db-ra a legfelso byte alapjan, maris csak 2 giga, ami total kenyelmesen kezelheto meg a legocskabb desktop gepen is. Eleg sokaig particionalod, meg egy C64 clusterrel is megcsinalod.

De amugy 1024 bites kulcsot te nem fogsz egykonnyen megtorni otthon.

De nem törni akarok! Olvasd el még1x.

saxus írta/wrote:
Masik megkozelites, hogy fakra bontod. Pl. lebontod 8-16 bites reszekre, ennek megfeloen lesz 128/64 szinted. A fa adott levelen azt tarolod, hogy milyen reszekbol van gyermekelem. Amikor keresel elkezded olvasni a bitsorozatod valamelyik iranybol (gyakorlatilag mindegy a sorrend is, lenyeg, h ugyanaz legyen minden kulcson :).

Ez rendben van, de hogyan applikálom ezt egy 32x32 bites mátrixra?

saxus (statz)

#9, Agyfasz (419)

403 | #1c77 | ^ | Idézet | Wed, 09 May 2012 16:59:14 +02

0.0.*.*

*.kgb.gov.su

TCH írta/wrote:
Ez rendben van, de hogyan applikálom ezt egy 32x32 bites mátrixra?

Matrixot felejtsd el, faban tarold.A fa emelei meg listak.

Es az a gond, hogy a mar ellenorzott kulcsokat tarolni kell. (Monjduk egy 1T-s vinyo az nem veszes koltseg meg a mostani inseges vinyoarak ellenere sem). 32x32 bites matrixot meg felfogod egy 128 byte hosszu tombnek.

saxus (statz)

#9, Agyfasz (419)

103 | #1c78 | ^ | Idézet | Wed, 09 May 2012 17:00:03 +02

0.0.*.*

*.kgb.gov.su

Uh, legyszi tegyel mar valami szurot, hogy a *.bussines.boardband.hu -t ne irja mar ki publikba. Koszi.

TCH (statz)

#1, Főfasz (10443)

1083 | #1c79 | ^ | Idézet | Wed, 09 May 2012 18:26:56 +02

46.107.*.*

*.catv.pool.telekom.hu

saxus írta/wrote:
Matrixot felejtsd el, faban tarold.A fa emelei meg listak.

A mátrix az én hash függvényemben van. 32 db 32 bites integer, azaz 32 sor és 32 oszlopnyi bit, ez össz 1024.

saxus írta/wrote:
Es az a gond, hogy a mar ellenorzott kulcsokat tarolni kell.

Nem mondod... -_-'
Szerinted mégis mi bajom lehet, nem pont ez?

saxus írta/wrote:
(Monjduk egy 1T-s vinyo az nem veszes koltseg meg a mostani inseges vinyoarak ellenere sem).

Az még annyira nem - noha most arra se nagyon lenne lóvé - de az alávaló vas az már igen. A gépem 2004-es. :P

saxus írta/wrote:
32x32 bites matrixot meg felfogod egy 128 byte hosszu tombnek.

Ööö...mi?

saxus írta/wrote:
Uh, legyszi tegyel mar valami szurot, hogy a *.bussines.boardband.hu -t ne irja mar ki publikba. Koszi.

Miért? Hogy ne lássák, hogy melóhelyen netezel? :P Majd kizúzom db-ből, filtert tuti nem teszek semmilyen címre.

djpety alias "Pety"

#6, Lófasz (953)

331 | #1c7a | ^ | Idézet | Wed, 09 May 2012 22:40:02 +02

188.6.*.*

*.dsl.pool.telekom.hu

TCH: A tesztelésben tudok segíteni, sőt, össze tudunk fogni, hiszen ezt lehet partícionálni. Egy részét ide dobod, aztán ráküldöm a vasat :)

Van 10GB ram (ebből ha nem használom fullon akkor 3-4GB szabad is), HDD-ből tudok 512GB szabad helyet. Ezenkívül még egy 4 magos Phenom II 965 @ 3,4GHz. Tehát ha kell, szívesen besegítek :)

saxus (statz)

#9, Agyfasz (419)

543 | #1c7b | ^ | Idézet | Thu, 10 May 2012 09:39:08 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
Miért? Hogy ne lássák, hogy melóhelyen netezel? :P

Nem baszki, hanem nem akarom a melóhely IP címét megosztani ország-világgal.

TCH írta/wrote:
Ööö...mi?

Ha egyezőséget akarsz keresni, szard le, hogy az mátrix. Ha összevonogatod az azonos részeket egy fában, kevesebb helyet fog foglalni. De tőlem oszthatod fix 32 bites részekre, csak úgy szerintem kevésbé jó lesz a helykihasználás, főleg az alsó részeknél. Példa:

imgpaste.com/G7Gy.png

TCH (statz)

#1, Főfasz (10443)

908 | #1c7c | ^ | Idézet | Thu, 10 May 2012 11:04:08 +02

46.107.*.*

*.catv.pool.telekom.hu

Pety: Köszi, elfogadom. Már csak ki kéne találni, hogy milyen algoritmussal nyomjuk. :P

saxus írta/wrote:
Nem baszki, hanem nem akarom a melóhely IP címét megosztani ország-világgal.

Aha. Csak ezzel az a baj, hogyha ezzel mászkálsz a neten, akkor megosztod ország-világgal amúgyis. De kitöröltem neked őket, örüllyél.

saxus írta/wrote:
Ha egyezőséget akarsz keresni, szard le, hogy az mátrix. Ha összevonogatod az azonos részeket egy fában, kevesebb helyet fog foglalni. De tőlem oszthatod fix 32 bites részekre, csak úgy szerintem kevésbé jó lesz a helykihasználás, főleg az alsó részeknél. Példa:

imgpaste.com/G7Gy.png

Értem. Na most akkor mekkora részekre daraboljam? 8 bitesekre? Csak azért mondom, hogy optimális esetben egyetlen ismétlést sem fogunk találni, vagyis a végén mindenképpen többszáz gigát eszik meg az egész.

saxus (statz)

#9, Agyfasz (419)

1300 | #1c7d | ^ | Idézet | Thu, 10 May 2012 15:03:29 +02

212.51.*.*

*.westel900.net

Minel nagyobbra a 8 bitet csak legvegso esetben hasznald, az mar iszonyu pici. Ezert mondtam h ne matrixban, hanem byte tombben tarold.

Masreszt ha osszeszamolod, akkorfenn 4, 8 byte hosszu kulcsot taroltam 21 byten, plusz kulc hozzaadasakor 22 byten 40 helyett. Persze nyilvan lesz overhead, mert tarolni kell h az adott levelen mekkora kulcsokat tarolsz meg valami modon ki kell talalni, hogy hogyan hivatkozol a kovetkezo levelre. (Emiatt az overhead miatt lehet nem is erdemes mondjuk 24-32 bitnel kisebbre venni a toredek meretet.

(Az mondjuk megoldas lehet, hogy mondjuk 2-3-4 bytet hasznalsz fajlnevnek a level kulcsanak elejebol (esetleg az egy v ket konyvtar), utana a fajlnevelso fele a listaelembol jon, masodik felenek a kulcsutkozesek elkerulese erdekeben vagy hozzatoldasz meg 1 bytet minden alindexhez, amit az UTF8-hoz hasonloan tudsz ugy kezelni hha felso byte 1, akkor meg nezzuk tovabb.

Persze meg tarolni kell azt is, hogy melyik 2-3 bytes indexnel hol jar ez a szamlalo.

Tarhelyben mondjuk lehet, hogy nem lesz kevesebb, de hogy keresni es modositani joval gyorsabban fogsz benne, mint ha az egeszet berendezed egy baszomnagy matrixba, abban szinte biztos vagyok.

Amugy ezt, h a listat felbontjuk tobb allistara, asszem mapreduce neven hivjak, de nem mernek megeskudni ra.

TCH (statz)

#1, Főfasz (10443)

1349 | #1c7e | ^ | Idézet | Thu, 10 May 2012 17:00:52 +02

46.107.*.*

*.catv.pool.telekom.hu

saxus írta/wrote:
lehet nem is erdemes mondjuk 24-32 bitnel kisebbre venni a toredek meretet.

Ok, akkor 32 bitesek lesznek.

saxus írta/wrote:
(Az mondjuk megoldas lehet, hogy mondjuk 2-3-4 bytet hasznalsz fajlnevnek a level kulcsanak elejebol (esetleg az egy v ket konyvtar)

A fájrendszerbe való írogatás gyorsabb, mint a fájlba való írogatás?

saxus írta/wrote:
Tarhelyben mondjuk lehet, hogy nem lesz kevesebb, de hogy keresni es modositani joval gyorsabban fogsz benne, mint ha az egeszet berendezed egy baszomnagy matrixba, abban szinte biztos vagyok.

*sigh* A mátrix nem a keresőben van, hanem magában a hash algoritmusban; hányszor mondjam még el? Faszom se akarta a legenerált értékeket mátrixban tárolni.

BTW, most eszembe jutott:

saxus írta/wrote:
(Ugyeeee nem megint valami olyat talaltal ki, mint anno, amikor egy 256 elemu stringben akartad megoldani a kategoriakat, mert nem akartal kapcsolotablat hasznalni?)

Nem azért taknyoltam stringekkel, mert nem akartam kapcsolótáblát használni, hanem mert akkor kezdtem mysql-ezni és fingom sem volt még a fogalmáról sem a kapcsolótáblának; el nem mondta senki, kénytelen voltam valamit alkotni php-ban. Így esett a nagy eset.

kemi (statz)

#2, Főfasz (2970)

85 | #1c7f | ^ | Idézet | Thu, 10 May 2012 17:05:13 +02

94.21.*.*

*.pool.digikabel.hu

Lehet valahogy manuálisan timeoutot előidézni egy FTP szerverrel? Debuggoláshoz kéne.