Bejelentkezés
Elfelejtett jelszó Regisztrálok
ápr11

Totó-suli – III. rész

 Totó-suli 9 hozzászólás

Mi nem vagyunk ennyire szigorú tanárok! :-) Folytatódik a mi kis Totó-sulink! A mostani rész a hibapontos kulcsok készítéséhez ad gyakorlati tanácsokat. Jó tanulást kedves “diákok”!… Hosszú, ám tanulságos rész következik!

Ezen új rovat célja, hogy a totókulcsok készítésének elméletével és gyakorlati megvalósításhoz szükséges útmutatókkal és tanácsokkal ismertesse meg a játékosokat.

Gyakorlati útmutató hibapontos kulcsok készítéséhez

Rögtön az elején tisztázzunk egy nagyon fontos dolgot. Ezzel a résszel nem szerezhető meg mindazon tudás, amely egy profi totóprogram használatát teljesen kiválthatná, de a programok működési alapelvének megértéséhez szükséges elveket tartalmazza. Ez a rész arra lesz elegendő, hogy megértése után egy kisebb, párszáz oszlopból álló variációt bárki képes legyen majd magának készíteni, és ehhez ne kelljen egy drága szoftvert megvásárolnia, amely rengeteg, az amatőr fogadó által nem ismert, és így számára használhatatlan funkciót is tartalmaz. Úgy is felfogható mindez, hogy a neten fellelhető ingyenes kulcsok előállításának a folyamatát fogjuk bemutatni egy teljesen másik kulcs elkészítésével.

Akinek az alábbiakban felsorolt módszerek nem elegendőek vagy megfelelőek, esetleg érthetetlenek, vagy túl bonyolultak, az vásároljon magának totókulcsokat tartalmazó könyveket, esetleg vegyen totókulcsokat, vagy magát a totóprogramot, esetleg tanuljon meg programozni és írjon magának egyet a saját szája íze szerint! Aki pedig túlfejlődött már ezen a szinten is, nosza rajta, ossza meg velünk a tudását!

Hibapontos kulcs készítésére több módszer is rendelkezésre áll, itt most hármat fogunk bemutatni, a két kisebb teljes variációból akár PCR-módszerrel (papír-ceruza-radír) akár Excel táblázat kezelővel elkészíthető egyszerűbb egy hibapontos kulcsot, illetve bármely teljes variáció leprogramozásának minimális oszlop szám szerinti elvi útmutatóját, amely akár szintén előállítható PCR vagy Excel segítségével, de rendkívül nyugodt és precíz jellem és birkatürelem kell hozzá, mert iszonyat sok munka!

Maradunk a fenti példánál, két háromesély és öt kétesély. Az egyszerűség kedvéért az öt kétesélyünk legyen mind 1X, a háromesélyek egyértelműek, a fixek pedig ennek a kulcsnak az elkészítése szempontjából lényegtelenek. Egy hibapontos kulcsot áll szándékunkban készíteni, ehhez az első lépés a teljes variáció leírása.

A teljes variáció a már fent leírt 288 variációból áll, kezdve az 1111111 variációtól a következő 111111X, 11111X1, 11111XX, 1111X11, stb. variációkon át az utolsó négy 22XXX11, 22XXX1X, 22XXXX1 és 22XXXXX variációkig. Célszerű a variációkat egymás alá írni. Excelben aki dolgozik, sorban egymás alá írja a variációkat, az egyes kimeneteleket pedig külön oszlopokba, azaz egy mező csak egy kimenetelt tartalmazzon, így könnyebb lesz velük később dolgozni. Megvan az alap, ezt kell most megszűrni!

Az egy hibapontos kulcs lényege, hogy elvileg olyan variációkat tartalmaz csak, amely bármely a kulcsban szereplő másik variációtól legalább két kimenetelben eltérnek. Vagyis ha a kulcsunkban megtalálható a 1111111-es variáció, akkor nem fog benne szerepelni többek között az 111111X, vagy az 1211111, esetleg az 111X111, stb. variációk. Kezd már derengeni?

Első lépés kiválasztani az első variációt. Legyen ez rögvest az első, azaz: 1111111. Ezt írjuk is le egy másik papírra, illetve Excelben másoljuk át az egész sort egy új fájlba vagy munkalapra. Megvan a kulcsunk első oszlopa, nevezzük ezt vezetősornak.

Most jön a hibaszűrés. Húzzuk ki mindazon sorokat a teljes variációból, amelyek a vezetősortól kevesebb, mint két eseménynél térnek el. Tíz ilyen variációt kell találnunk: kilenc pont eggyel fog eltérni, egy pedig nulla eltéréssel saját maga a vezetősor lesz, nyilván. Húzzuk ki őket, a továbbiakban velük már nem számolunk. Excelben ez egy pici kulcs, tehát ezek az oszlopok nyugodtan törölhetőek most, de ha valaki több tízezer oszlopból akar majd szűrni, a törléssel percekig belassíthatja az Office-t, figyelni! Az eltérés sima IF és SUM (magyarul HA és SZUM) függvényekkel kalkuláltatható, erre nem akarunk kitérni, mert alap műveletek. Ha mégis szükség lenne rá, tessék igényelni hozzászólásban!

Maradt 278 variációnk. Melyik legyen a következő? A legkézenfekvőbb módszer mindig a legfelső még meglévő oszlop kiválasztása (az 11111XX), kiírása/átmásolása, majd ezt már, mint új vezetősort szűrni, és ezt az egészet elölről újra és újra és újra – így is végig lehet menni az eredeti teljes variáció elfogyásáig. Fontos, hogy ekkor egyrészt az első tippek gyakorisága nagyobb lesz következőknél, azaz a kulcs a háromesélyeknél több 1-est fog tartalmazni, mint X-et, 2-esből meg csak egy keveset, és a kétesélynél is jelentősen több 1-es kimenetel lesz, mint X; másrészt pedig 44 oszlop helyett 80-100 oszloppal kell számolni végeredményként. Persze ez hibátlan alaptipp esetén növeli a teli esélyét, elvégre valamit valamiért.

Jobb eloszlást biztosító módszer, hogy ha a második (és aztán mindig a következő) kulcsban szereplő variáció a vezetősortól az eredeti teljes variációban az első legnagyobb eltérést mutató variáció lesz, esetünkben az XXXXXXX, ezt kell kiírni/átmásolni, majd ezt már mint új vezetősort szűrni – és újra és újra és újra az eredeti teljes variáció elfogyásáig. Látható lesz, hogy a tippek már normálisabb eloszlást mutatnak, de még mindig olyan 50-70 oszlop az eredmény. Hogy lesz ebből 44?

A 44 az egyik lehetséges elméleti minimum. Az előállítás elmélete a következő: még a teljes 288-as variáció minden egyes sorát egyenként megvizsgáljuk, hogy a többitől mennyivel tér el, de csak a kettőnél kevesebb eltérések számát jegyezve. Tehát végül mindegyik variációhoz fog tartozni egy szám, hogy a többitől legfeljebb eggyel hány esetben tér el. Ezen új információ alapján meg kell keresni, hogy ez a szám hol a legnagyobb, majd az ahhoz tartozó első variáció lesz a kulcs első eleme és egyben vezetősora. Szűrés és törlés a fentiek alapján, majd kezdjük az egészet elölről: újra minden egyes elemet megvizsgálni… és újra és újra és újra… Nagy munkának tűnik? Az is! Ez csak pici kulcs, mégis napokig tartana kézzel vagy Excelben így előállítani, ráadásul mivel elég komplex, lassú és monoton művelet, jó esély van hibát elkövetni benne – egy programnak a teljes küldetés pár másodperc csupán, zéró hibalehetőséggel.

A gyakorlati megvalósítás programnyelv ismeretétől függ – aki tudja, érti.

Két, illetve három hibapont esetén ugyanezek az elvek érvényesek, csak azokat a sorokat kell szűrni, amelyek a vezetősortól kevesebb, mint három, illetve négy eseménynél térnek el. Kevesebb, mint – ezt nem véletlenül írom, bár ugyanazt jelenti, mint a legfeljebb vagy maximum, de aki Excelt használ, annak sokat fog segíteni ez a megfogalmazás.

Általában elmondható, hogy az egy hibapontos kulcsok a teljes variációt a hetedére, a két hibapontosak a huszadára, a három hibapontosak a hatvanadára csökkentik – ennek alapján a teljes variáció oszlopszámának ismeretében nagyjából megbecsülhető az egyes kulcsok mérete.

Áron



Hozzászólások
  • zso január 06. 12:23 (#1) | Válaszolok

    Áron, leprogramoztam a fentebbi módszert. A 2-5-6 példára jól működik, de például az 1-9-3 esetben 1 hibaponttal számolva 192 elemű kulcsot ad, miközben van 160 elemű kulcs is, az elméleti minimum. Világos, hogy úgy kell választani a vezetősort, hogy a lehető legtöbbet kihúzhassam vele, de ha több ilyen is van, akkor még ott lehet optimalizálni, hogy azok közül melyiket válasszam.

    Nekem ha a teljes variáció <5000 elemű, akkor mondhatom, hogy gyorsan működik. Mert egyébként a programnak sem pár máodperc N elemet N elemmel összehasonlítani, ráadásul ezt annyiszor, ahányszor vezetősort választok.

    Nem vagyok elégedetlen, mert már ez is jóval hatékonyabb, mint az eddigi programom, ami az 1-9-3 esetre kb. 300 oszlopot adott, mert véletlenszerűen vette mindig az új vezetősort.

  • euroaron január 06. 12:54 (#2) | Válaszolok

    zso, rengeteg lehetőség van.

    valamelyik hozzászólásban benne is volt, hogy évekig tartana megtalálni egy magasabb index optimális hibapontos kulcsát. választgatás, optimalizálás… na, pont erről beszélsz te is. hát, ha van időd, nosza rajta! :)

    a gépemen pl 25e variáns egy hibapontosra kialakítása kb 20-25 órát vesz igánybe, úgy, hogy a gép kb 300-320e műveletet végez el másodpercenként… és akkor az még ugye nem is az elméleti minimum. bár ez a gép közepes teljesítményű, az otthoni meg olyan 180e sebességgel húz.

  • zso január 06. 14:11 (#3) | Válaszolok

    Rendben, nem szemrehányás volt a fenti.
    Csak azt írtad, hogy “egy programnak a teljes küldetés pár másodperc csupán, zéró hibalehetőséggel.
    A gyakorlati megvalósítás programnyelv ismeretétől függ – aki tudja, érti.” Ezért gondoltam, hogy ügyesebben csináltad mint én. Ugyanis el tudom képzelni, hogy 1111111 megvizsgálása után 111111X-et már nem kell megvizsgálni, csak 1111111-hez tartozó értéket átírni, ha szimmetrikus a teljes variáció (márpedig ha valaki az alaptippet nem szűri, akkor az az).
    Az elemek vizsgálatát nem kell többször elvégezni, elég lenne csak egyszer, legelőször. Ez 25e variáns esetén még el is fér a memóriában. A nagyobb gond ahogy írtad magával a számolással van.
    De itt megállok, nem ebből akarom írni a doktorimat. :D

  • euroaron január 06. 14:18 (#4) | Válaszolok

    a pár másodperc párszáz variánsra vonatkozott, egész pontosan a példára = 288! :)

    mondjuk lehetne úgyis, hogy az eredményt kiírom egy szövegfájlba, aztán abból mindig beolvasom memóba apránként, majd visszaírom a változásokat. csak az nem tudom, hogy gyorsabb-e?
    feltételezem, hogy igen, mert ott nem kell mindig újraszámolni, csak vizsgálni, meg a szűrés után visszaíratni a fájlba a módosítást. melyik gyorsabb vajon?
    filó…

  • euroaron január 06. 14:20 (#5) | Válaszolok

    de… mondjuk ha bázis ötvenezer variánst akarok n hibapontra szerkeszteni, mindegy hogyan, akkor az már régen rossz… :) ))

  • zso január 06. 14:43 (#6) | Válaszolok

    Nekem most fájlba ír a program, mert a korábbi verziót Pascalban írtam, és nem akartam korlátozni az alaptipp méretét. Viszont tudomásom szerint Pascalban előre meg kell mondani a tömb méretét, és egy 3^13 méretű tömb deklarálása után “stack owerflow” miatt le sem fordult a progi…
    De mondom, az egyszeri számolás már önmagában sok, igaz én csak 15 percig vártam 40e variánsnál és kilőttem, mert alig jutott valamire.

  • euroaron január 06. 15:03 (#7) | Válaszolok

    zso, javaban is meg kell mondani a tömb méretét, de ha vektort használsz, akkor az mivel dinamikus tömb, akármikor bővíthető, vagy éppenséggel csökkenthető méretű.
    úgyhogy én definiálásra kisméretű tömböket használok, a variánsok pedig vektorban tárolva.
    és így már csak memó függvénye.

    javascriptben meg a tömb, az teljesen dinamikus, bármikor bővíthető.

  • zso január 06. 19:08 (#8) | Válaszolok

    Hú, én már 3-4 éve nem programozok. Meg is lepődtem, milyen könnyen ment vasárnap a módosítás. Pascal-t tanultam, javat meg ilyen c-szerű nyelveket nem ismerem. Azért egy 40e x 40e mátrix ha 2bytos elemei vannak is, több mint 1GB-ot lefogal, ha jól számolom. Az összehasonlítgatóst részt arra gondoltam, meg kéne majd próbálni awk-ban, nem programoztam még benne, de ez a nyelv direkt szövegmanipulációs feladatokra van kitalálva és gyors. És ha már úgyis unix alatt írom, akkor egy erős szerveren csak gyorsabban fut. Bár az N*N összehasonlítás akkor sem úszható meg.

  • ErA október 26. 08:29 (#9) | Ez egy válasz erre: #6 | Válaszolok

    Használj pointer-láncot, fordíts védett módban, akkor csak a fizikai memóriaméret korlátoz.


Szólj hozzá Te is!



Heti totó tippek (8/1. hét)

1. FC Köbenhavn - Chelsea 2
2. Lyon - Real Madrid 2
3. Internazionale - Bayern München 2
4. Marseille - Manchester Utd. 2
5. Blackpool - Tottenham 2
6. Arsenal - Stoke City 1
7. Porto - Sevilla 1
8. Liverpool - Sparta Praha 1
9. PSV - Lille 1,x
10. Sporting CP - Rangers 1
11. Ajax - Anderlecht 1
12. Villarreal - Napoli 1
13. Twente - Rubin Kazany 1
+1. VfB Stuttgart - Benfica x

Kiemelt tippmixek

Holnap, 17:45 Porto - Sevilla 1.75|3.35|4.15
Holnap, 20:30 Internazionale - Bayern München 2.11|3.25|3.05
Holnap, 20:30 Marseille - Manchester Utd. 3.30|3.00|2.10

Totó eredmények (7/2. hét)

1. Dortmund - St. Pauli 1
2. Freiburg - Wolfsburg 1
3. Hamburg - Werder Bremen 1
4. Hannover - Kaiserslautern 1
5. Hoffenheim - 1. FC Köln x
6. Mainz - Bayern München 2
7. Bayer Leverkusen - VfB Stuttgart 1
8. Bologna - Palermo 1
9. Internazionale - Cagliari 1
10. Lecce - Juventus 1
11. Chievo - Milan 2
12. Genoa - Roma 1
13. Fiorentina - Sampdoria x
+1. Mönchengladbach - Schalke 1
Mito