Červenou barvou pirátovy krve jsem znázornil reprezentaci prvního bajtu (písmono r v naší ukázce). Celý problém se dal zobecnit, jestli bity, skupiny dvou a čtyř bitů, bajty, rozdání (23 bajtů) či celý soubor číst normálně, nebo pozpátku, a v jakém pořadí. Říkal jsem si, kdo mě za co trestá, a že tedy asi lidstvu užitečný nebudu. Že možná na tom pustém ostrově umřu sám a zapomenut.

Dobrodruhům srdcem vlastním nebudu popisovat co vše jsem s těmi nulami a jedničkami zkusil/zažil. Na konci druhého dne jsem téměř vyčerpán žádal Pavlicka o radu, pokud to tedy není hádanka, a může-li mi pomoci. Poslal tip, že kódování Little endian je opravdu vztaženo na bajty, nikoliv na čtyři bity, což byl můj poslední vzorek té minuty. Áha!

Hi Pavel,
Your sample.txt:
2725a7a01ea74e9f250e14cfc794949494b2a293937676
My hex dump of rpxx.bin:
72527A0AE17AE4F952E041FC7C494949492B2A39396767
So it's apparent you have swapped the high and low nibbles of each byte. First byte is 72h = 01110010b. Second byte is 52h = 01010010b, etc.
Perhaps you thought "little endian" pertains to nibbles; but no, it only applies to byte order.
-Richard

Ale nic! Po mnoha pokusech jsem přestával rozeznávat stranu levou a pravou stranu, vysoká či nízká mi bylo jedno, už jsem nevěděl, jestli A je nejvyšší karta zleva, či nejnižší zprava, a vůbec! Začal jsem i pochybovat, jestli vůbec umím programovat. Špinavý, smrdící a zablácený jako zlatokop jsem byl ztracen. Ke konci třetího dne jsem si už na pokraji svých sil říkal, že zde sranda končí, že se musím vrátit do reality a že je to na mě moc. Problém jsem odložil, pomocné soubory uzavřel, papírové poznámky přesunul mimo pohled očí a z dosahu rukou. Konec příběhu!

Jenže ráno jsem vstal a čekal mě na kompíku email, že Pavlicek rozšířil svůj BFC konvertor [Bridge File Converter, na začátku článku ve verzi 4.0, na konci sepisování ve verzi 4.3, bfc.txt a bfcsetup.exe] o tyto dva formáty (z dosavadních 10, včetně PBN, LIN a dalších, speciálně výhodná je LIN->PBN konverze v těchto dnech), o ZRD (Richard's Solved Random Deals) a ZSD (Richard's Solved Symmetric Deals), a že by mě to možná mohlo i zajímat! Možná taky zajímalo a jak! Vstal jsem z (polo)mrtvých.

Aha, říkal jsem si, takže nakonec to přecejenom běžné binární soubory byly i nebyly! Takový podvod i nepodvod na ubohého řešitele. Karetní bůh se smiloval nad smrtelným nešťastníkem! Do kronik vepište a na hrob mi dejte: Léta Páně 2013, 17. května, BFC, verze 4.3.

Hi Pavel,
This may interest you... The file RPXX.BIN is now named RPXX.ZRD to identify the file format, which my Bridge File Converter will now convert automatically to any other format. (Likewise, files RP01.BIN to RP10.BIN are now RP01.ZRD to RP10.ZRD.)
Similarly, the solved symmetric deals (RPSX.BIN and RPSD.BIN) are now RPSX.ZSD and RPSD.ZSD to identify another format that my BFC now converts.
-Richard

Nalilo to do mě novou krev, když už jsem to vzdal, tak to zkusím dorazit jen tak, už jen pro zábavu. Než dorazila vidina řešení, tak jsem mohl (dokonce automatem, kdyby na to přišlo) kontrolovat, zda-li každý hráč má 13 karet (když se sešlo moc nul, měl moc karet Západ, když moc jedniček u sebe, měl jich mnoho Jih ap.), dále, zda-li počet zdvihů je v rozmezí 0 až 13 karet (lítalo to do 15, když se sešly čtyři jedničky). Takový postup jsem vyřadil hned, občas tyto ukazatele seděly a pak neseděly počty zdvihů vůči nezávislému propočtu. Tedy rozdání bylo zdánlivě karetně v pořádku, počty zdvihů zdánlivě také, ale neseděly k sobě.

Abych věděl, kde je první a kde poslední rozdání z oněch 4000, tak jsem si na úrovni bajtů (Ctrl+C a Ctrl+V by nám nestačilo, neb jsou tam řídicí znaky, to jsou znaky v šestnáctkové soutavě 00 až 1F; je to vidět i na naší ukázce na čtvrtém znaku, kdy HTML zakazuje řídicí znaky zobrazovat a je tam mezera), který v hexa či binárně, vyextrahoval prvních 23 bajtů do souboru exp.zrd [], exp jako experiment, a poslal jsem to do Pavlickova konvertoru, přesněji:

Získal jsem veledůležitý rozpis prvního rozdání v souboru out.pbn []:

% PBN created by BFC.EXE exp.zrd p
[Event ""]
[Site ""]
[Date ""]
[Board ""]
[West ""]
[North ""]
[East ""]
[South ""]
[Dealer ""]
[Vulnerable ""]
[Deal "W:K9.KQT3.743.QJ95 J873.J42.Q65.KT2
       AT652.A976.AJ82. Q4.85.KT9.A87643"]
[Scoring ""]
[Declarer ""]
[Contract ""]
[Result ""]
{RBNM ::44236=:99B97+99A97}

A zobrazil jsem si to něco už jako bridžové rozdání. DD/DTH analýza je ta tabulka uprostřed, kde je obvykle bridžový stůl.

(V roce 2011 jsem se pokusil přeložit rozhraní u programu DD Solver [odkaz], připomínky prosím posílejte emailem, kdyby něco bylo chybně, zkusil bych to zapracovat a autorovi bych zaslal opravenku.)

To jsem si říkal, že to nevzdám a šel jsem za tím jak uslintaný bernardýn! Začal jsem od řešení jít zpátky kam to jen šlo, eso pikové je u Východu, Východ je v návodu (00 Západ, 01 Sever, 10 Východ, 11 Jih) jako binární hodnota 10, další karta je král pikový u Západu atd. Dostal jsem řadu:

Slzy radosti jsem měl na krajíčku očí, tímto musí řada začít nebo končit a srovnal jsem to se svými pokusy. Bohužel nikde nic. Pokračoval jsem rozkladem ve dvou bitech u karet a ve čtyřech bitech u zdvihů. A pak jsem to uviděl! Úplně někde v dáli.

Když prohodím bajty (dva hexy) od konce (reverzně alias Little endian), tedy končím sekvencí, kterou jsem začínal: ...e1 0a 7a 52 72, dám do binární řady, budu číst uvnitř bajtu vždy dva bity zprava doleva (lidsky reverzně), ale se zápisem zleva doprava (informaticky reverzně), dostáváme (začínáme to číst nulou na druhém řádku):

Vyzískáme, čteno od konce, řadu začínající 10001101 10000101..., a to jsme hledali. Samozřejmě u zdvihů (4 bity) to tak je pro čtyři bity, nikoliv jen pro dva. Karet je 52 a byly potřeba dva bity, takže z celkového počtu 184 bitů bylo na karty potřeba 104 bitů, zbytek (20 sehrávek a čtyři bity k uložení informace 0 až 13 (d) zdvihů) zůstalo 80 bitů, tedy 10 bajtů, které se rozpadly na 20 hexa čísel. Ty už stačilo prohodit, nikoliv řešit na úrovni bitů. Obdržíme:

To je v pořadí Západ, Sever, Východ, Jih, a to už můžeme vyčíst z náhledu v programu Double Dummy Solver (DDS).

Šťastný jsem byl jako blecha!

Můj drobný program v Pythonu dvojkové řady [odkaz; aktuálně ve verzi 2.7.3] konečně vypsal tížené, tedy:

První řádek jsou karty Západu, druhý pak Severu, třetí Východu a předposlední řádek patří Jihu, vnitřní entici tvoří karty, seřazené zleva: piky, srdce, kára a trefy. Karty v barvě jsou setříděné sestupně. Pátý řádek jsou právě zdvihy, vnější entice je zleva bez trumfu až po trefy a vnitřní entice od Západu po Jih. Tohle pak už konvertítko přeházelo, jak bylo potřeba.

Program byl za zásluhy a věrné služby povýšen do šlechtického stavu! To však ještě konvertítko nevědělo, čeká jej ještě mnohé překvapení: milióny rozdání, tohle byl jeden kus. Jinak těch deset miliónů rozdání žádný bridžový hráč nezvládne sehrát. Kdyby člověk zvládl 300 rozdání denně (Je to reálné? Možné to asi je u bridžových marathonů po kratší období.) a hrál 300 dní v roce po dobu 50 let, tak se dostane na cca slabší polovinu (4.500.000 rozdání). Snad jsem se neustřelil v nějaké té nule.

Důvěřuj, ale prověřuj!

Ale co nezávislá kontrola? Ne že bych Pavlickovi, jako Grandmasterovi/Mistrovi, nevěřil, ale pirát je pořád pirátem a pirátem zůstane. Nevěřím mu! Vědecká presumpce viny! Vědec je vinen za své pokusy, dokud vědecky neprokáže opak.

Mohl jsem to zkontrolovat rovnou v DDS, ale co když tyto Pavlickovy výsledky program z PBN přebírá, to není žádná kontrola! Musel bych editovat PBN soubor a zkusit DDS znovu. Nebo byla potřeba pomocného programu, který odevzdá v rozumném formátu jen karty a zdvihy se dopočítají. Takový automatizační nástroj máme.

Provedu vás v pěti minutách bridžovou hračkou, programem Deal [odkaz], takový vstup pro neznalé. Těchto hraček v průběhu dvaceti let najdeme mnoho [odkaz či odkaz], ale Deal se uplatnil, neb je volně dostupný, se zdrojovými kódy, je programovatelný a i firma BBO jej snadno implementovala. Člověk by si řekl, že je jedno, jak se těch 52 karet rozdá, nu, není to jedno! Existuje dokonce celá oblast pravděpodobnosti a matematické statistiky, která měří vyčíslitelnou náhodnost těchto pseudonáhodných čísel (angl. randomness). Fyzici tvrdí, že mají už skutečný náhodný generátor, ale matičce Přírodě bych kolem náhody zrovna nevěřil [odkaz]. Měří se buď atmosférický šum, nebo kosmický šum, nebo se měří fotoluminiscence ap., a to se převádí z videa (zvuk a/či obraz) na bity. Takže už žádné házení hrací kostkou, volbu cifer od čísla pí či nedejbůh matematicky exaktně jako u dnešních pseudonáhodných čísel, dodávám s úsměvem.

Dodatek: BBO téměř jistě generuje rozdání vlastními prostředky, na testování a pro generování pro uživatele používá program Dealer [odkaz]. To je alternativa programu Deal z dílny Hans van Staverena [odkaz]. Navíc autor v manuálu dokonce nedoporučil svůj program na rozdání pro turnaje, neb si není jistý dostatečnou náhodností. Zajímavou variantou (vygenerování 10000 rozdání a vybrání těch „ulítlejších“) mají zde [Hand Generator – Goulash]. To se hodí na speciální tréninky a do společenského prostředí.

Zpět do informatické reality. Program si stáhneme do své složky z těchto stránek [odkaz], rozpakujeme. Uvážím verzi pro Windows, Linuxáci znají. Najdeme tam především spustitelný soubor deal.exe. Z příkazové řádky si můžeme zkusit po zapsání a potvrzením klávesou Enter tento první experiment:

Obdržíme pseudonáhodně vygenerované rozdání:

Zde přikládám další tipy:

V prvním případě se vypíše dvacet rozdání v článkovém formátu, v druhé ukázce rozdání vměstnané do jednoho řádku a v poslední ukázce dvacet rozdání, ale s dopočtem maxima zdvihů pro obě linky a všechny barvy i beztrumfový závazek.

Programátoři zajásají, že se s tím dá dát dál hrát, nastavit podmínky a omezení všeho možného i nemožného atd., přeskakuji, to je na samostatný příspěvek (zvlášť důležité je, že můžeme konkrétnímu hráči zafixovat karty, například jednomu všech 13 nebo dvěma hráčům 26 karet a rozdávat zbylé karty, to je klíčové pro všechny analýzy: ať už u licitace, výnosu, obrany i sehrávky) či překlad manuálu autora programu, zde se zaměříme na výpis do souboru, to bude takto:

V souboru rozdani.txt [] máme něco takového (vy však určitě jiné rozdání, neb počáteční hodnota pro pseudogenerátor, tzv. seed, nebyla nastavena):

Do souboru rozdani.txt se nám uloží jedno rozdání bez DD zdvihů. To však můžeme znovu vzít a nechat DD dopočítat plus výstupy rovnou přesměrujeme do souboru rozdani-reseni.txt [].

Dostáváme v tomto souboru:

Pozn. Pokud bychom místo jedničky dali například 32, tak za pár desítek minut budeme mít v souboru rozdani-dd.txt [] svou první, malou kolekci rozdání na turnájek (při parametru -l), nebo i s DD:

To je přesně to, co kvůli kontrole potřebujeme. Na vstupu budeme mít 52 karet, na výstupu výpočty zdvihů. Jen předesílám, že si musíme dát pozor na to, kolik rozdání v souboru máme, standardně Deal pracuje jen s desítkou souborů, není-li zadána hodnota, musíme mu to upřesnit číslem, přesněji vstupním parametrem programu.

Jedna poznámečka. Podrobnou nápovědu, návody a ukázky najdeme na oficiální stránce autora [odkaz], kratičkou nápovědu dostaneme zapsáním chybného parametru:

Získáme:

Vidíme následující: podrobnější výpis běhu programu (-v, verbose), nastavení počáteční hodnoty pro pseudogenerátor (-s, seed), vstupní/zpracovávaný soubor (-i, include), načítaný/výstupní formát (-I, input) a počet rozdání (count, číslo). Především nás zajímá přepínač -s, tím totiž dostaneme pseudonáhodné řešení (jinak se nejčastěji volí přepis systémoho času počítače), ale tento parametr nám zajistí, že to samé rozdání dostaneme znovu. Takto bychom byli například schopni reprodukovat dřívější sadu rozdání (jinak nemáme šanci se k rozdání znovu dopracovat, systémový čas pracuje s milisekundami; jen obecně pozor, že algoritmy generování se se změnou verze programu mohou změnit, mám to neblaze ověřené u Pythonu, i když dokumentace to zmínila):

Při opětovném spuštění této řádky vy i já dostaneme naprosto to samé, tedy:

Musíme si dát pozor na několik věcí, pokud používáme tento druh reprodukovatelného pseudonáhodného generování, nesmíme použít tu samou hodnotu několikrát, pak by turnaj byl se stejnými rozdáními. Hodnota může být záporné číslo (což systémový čas nikdy nebude), ale je to celočíselná hodnota a musíme si dát pozor, v jakém intervalu se smíme pohybovat.

Když zapíšeme (je tam tucet devítek):

A opětovně spustíme, dostaneme to samé rozdání, vše je zdánlivě v pořádku. Jenže když zapíšeme hodnoty blízké, např. 9999999999989 či 9999999999991, dostaneme opět to samé rozdání.

Nepomůžeme si ani velkými zápornými čísly. V následujícím bloku sice obdržíme jiné rozdání než doposud, ale princip je stejný a získáme stejné rozdání pro tuto šestici:

Ani práce s desetinnými čísly nepomůže. Desetinná část je odstraněna, uříznuta, nikoliv zaokrouhlena.

Děsivé, že? A hlavně nepřijatelné. Důvod je ten, že Deal příliš velké, kladné či záporné hodnoty, nastaví na nejbližší přípustnou kladnou/zápornou hodnotu a s tou pracuje. Takže pokud byste v pondělí použili obrovské číslo končící 89, v úterý 90 a ve středu 91, všichni přítomní by se divili.

Formálně z pohledu programování je to v pořádku, ale když dojde k takovému vnitřnímu zásahu (vypadá to na zlom někde kolem deváté-desáté cifry), uživatel by měl být informován výpisem zprávičky od programu. Ještě lépe by měl být uživatel požádán o zadání čísla v určitém rozsahu. Přesně to nemám ze zdrojových kódů zjištěné, ale ten použitelný radius se pohybuje kolem plus mínus devíti cifer. Zároveň to píši autorovi programu, že se program chová zvláštně/nebridžově v této situaci a není to hlídáno. Ten, kdo použije své rodné číslo plus například číslo roku, měsíce a dne v roce (9 nebo 10 cifer), by měl už problémy.

Mj. na rok+měsíc+den velký pozor, jejich součet bez řídicích nul není vždy rozdílný, například:

je to to samé jako například:

jako počáteční hodnota pro pseudogenerátory je tedy tento součet nevhodný, není jedinečný. Proto se používá časová známka (angl. timestamp), což je přepis den-měsíc-rok 20052013 (nikdo netřídí prvně dle dne), tedy kvůli třídění výhodnější rok-měsíc-den: 20130520. Červenou jsem zaznačil měsíc. Nepíšeme jen pětku, ale nula pět, aby se správně třídily jedno- a dvouciferné dny a měsíce. Pokud by mohl nastat konflikt v jednom dni (turnaj ráno, odpoledne a večer), tak se časová známka rozšiřuje o hodinu, minutu a vteřinu, a je-li potřeba, tak i milisekundu. Aby se té milisekundě dalo vyhnout, tak se zpracování dvou záznamů na některých serverech zpomaluje o alespoň jednu celou vteřinu (i když důvod je častěji rovnoměrnější zatížení serveru). Tím je zaručeno, že časová známka končící vteřinou bude u dvou záznamů různá.

Informatici, budou-li se tak v budoucnu nazývat, já tipuji termín virtualizátoři, budou řešit zajímavý technický problém na přelomu roku 9999 a 10000, kdy se budou muset zpětně přehodnotit čtyřciferné roky na nula+rok, tedy letošní rok, 2013, by byl zapsán jako 02013. Ale to není aktuální problém. Značka se z osmi cifer stane devíticifernou, takže jednoznačná bude, jen ta délka řetězce se změní a to může ovlivnit parsování.

Až někdo objeví, jak se tato počáteční hodnota pseudogenerátoru na BBO nastavuje, má šanci se dostat k rozdáním ještě před vlastní hrou na BBO. Kdo by to však dělal, že? Bridž by nebyla taková zábava.

Před lety i před pár týdny jsem na BBO Forums napsal, že by se hodilo, kdyby tabulka DD byla k vidění po sehrávce. Ale jen tak to není. Pokud výpočet může zabrat i hodinu, bylo by potřeba generovaná rozdání předvypočítat (zdvihy, případně i par/minimax), uložit do fronty, a to není zas tak jednoduché než když jen nabídnete prosté rozdání 52 karet, což se dá udělat na koleně do sekundy i v pomalém programovacím jazyce.

Vraťme se do pirátské reality. Teď došlo opět na Python. Svého Konvertora jsem rozšířil o výpis a pasoval na Velkého konvertora, záměrně jsem to parsoval na co nejmenší elementy (entice uvnitř entic), abych se později vyhnul zpětnému parsování, např. „S“ pro eso pikové v „SA“ ap.

Spuštění je:

Už se na pustém ostrově ztrácím při cestě od pokladu, ale Konvertor vypsal dva soubory, 1testuj.txt [], kde jsou jen karty ve formátu vstřebalném pro program Deal, pro naše první rozdání u Pavlicka to je:

A druhý soubor, 2overen.txt [], obsahuje karty i zdvihy na následné ověřování, tedy:

Vidíme, že se oddělovače mezi barvami v Dealu liší, ale to už Konvertor zvládá.

První soubor podstrčíme Dealu na výpočty a rovnou výsledky vypíšeme do pomocného souboru 3deal.txt [] kvůli srovnání (zde i na web dám z Pavlickova vzorku 4000 rozdání vzorek o prvních 32 rozdáních):

Pokud pracujete s CygWinem [odkaz] a nebo již rovnou na Linuxu či Mac OS X, tak máme k dispozici nástroj diff ke srovnávání souborů. Spustíme jej takto:

Nástroj diff nic nenapíše, takže jsou soubory identické, na úrovni všeho, na úrovni řádků, rozdání, bajtů, bloku bitů, atomů, kvarků, ale hlavně bitů! Dobře to Pavlicek spočítal, dobře!

Poněvadž jsou soubory identické, je jedno, který použijeme na konverzi do něčeho vstřebatelného pro lidské oči:

Získáme v souboru 4deal.pbn [] první rozdání ze 32 v této formě:

[Date "1965.01.01"]
[Board "1"]
[West "West"]
[North "North"]
[East "East"]
[South "South"]
[Dealer "N"]
[Vulnerable "None"]
[Deal "N:J873.J42.Q65.KT2 AT652.A976.AJ82. Q4.85.KT9.A87643 K9.KQT3.743.QJ95"]
[Contract "4H"]
[Declarer "W"]
[Result "11"]
[Score "NS -450"]
{
          S: J873
          H: J42
          D: Q65
          C: KT2
 S: K9             S: AT652
 H: KQT3           H: A976
 D: 743            D: AJ82
 C: QJ95           C: ---
          S: Q4
          H: 85
          D: KT9
          C: A87643
north makes 6 tricks in clubs
north makes 3 tricks in diamonds
north makes 2 tricks in hearts
north makes 4 tricks in spades
north makes 4 tricks in notrump
east makes 7 tricks in clubs
east makes 9 tricks in diamonds
east makes 10 tricks in hearts
east makes 9 tricks in spades
east makes 9 tricks in notrump
south makes 6 tricks in clubs
south makes 3 tricks in diamonds
south makes 2 tricks in hearts
south makes 4 tricks in spades
south makes 4 tricks in notrump
west makes 7 tricks in clubs
west makes 9 tricks in diamonds
west makes 11 tricks in hearts
west makes 9 tricks in spades
west makes 9 tricks in notrump
}
[Auction "N"]
Pass   Pass   Pass   4H
[Play "N"]
*

Informace o zdvizích v komentáři jsou seřazeny zas úplně jinak než doposud... Člověk by si měl vzít pirátskou bambitku a odprásknout se.

Deal nás jen informuje, které rozdání zpracovává, kdo je rozdávajícím (točí se ve směru hodinových ručiček) a kdo je ve hře (točí se proti směru hodinových ručiček). Takto to vypadá pro 32 rozdání:

Computing par for deal 1 north None
Computing par for deal 2 east NS
Computing par for deal 3 south EW
Computing par for deal 4 west All
Computing par for deal 5 north NS
Computing par for deal 6 east EW
Computing par for deal 7 south All
Computing par for deal 8 west None
Computing par for deal 9 north EW
Computing par for deal 10 east All
Computing par for deal 11 south None
Computing par for deal 12 west NS
Computing par for deal 13 north All
Computing par for deal 14 east None
Computing par for deal 15 south NS
Computing par for deal 16 west EW
Computing par for deal 17 north None
Computing par for deal 18 east NS
Computing par for deal 19 south EW
Computing par for deal 20 west All
Computing par for deal 21 north NS
Computing par for deal 22 east EW
Computing par for deal 23 south All
Computing par for deal 24 west None
Computing par for deal 25 north EW
Computing par for deal 26 east All
Computing par for deal 27 south None
Computing par for deal 28 west NS
Computing par for deal 29 north All
Computing par for deal 30 east None
Computing par for deal 31 south NS
Computing par for deal 32 west EW

Formát PBN [odkaz], znám i šachistům, si můžete otevřít ve vašem oblíbeném bridžovém programu. Formát sice drobně Pavlicek kritizuje, že se dá stáhnout na třetinu původní velikosti, ale to je drobnost.

My se hlavně dozvíme, že u prvního rozdání je par/minimax 4W+1 za -450 pro linku Sever-Jih, a o to tu šlo! Bo Hugland totiž nedávno rozšířil svou knihovnu o výpočet paru, Deal toho umí využít (to je ten parametr format/par, resp. alias format/gibpar, nebo format/parArticle). Umí to i Double Dummy Solver a další produkty.

Jak si vypsat všechny závazky rovny paru (může to být závazek hrán od obou stran stolu, můžeme například mít rozdání, kde je možné hrát 2= i 2= ap.), o tom bude jiná článková pohádka. Dobrou noc, piráti a pirátky!

Nebo, nebo si ještě v rychlosti můžeme vyřešit i tento problém. Například kdo bude rozdávajícím 1634. rozdání a v jaké hře budou linky?

Poněvadž se běh opakuje pro čtyři hráče, budeme se zabývat dělením po zbytku čtyřmi, proto hráče zaznačíme 0 pro Sever, 1 pro Východ, 2 pro Jih a 3 pro Západ. Zbytek po dělení čtyřmi 4 bychom nikdy nedostali (zbytek je nula). Sever tedy bude hrát 0, 4, 8, 12, ... rozdání. Číslování rozdání však začíná jedničkou, tedy od zadaného čísla pořadí odečteme jedničku. Zjistíme zbytek po dělení čtyřmi a dle klíče vypíšeme hráče.

1634 mínus 1 je 1633. Po vydělení čtyřmi získáváme 408,25, desetinná část je 0,25 a zpětně vynásobíme čtyřmi. Zbytek je 1. To je Východ. Je to spočteno na řádku 10, vypsáno na řádku 14 dále uvedeného zdrojového kódu.

Pozn. Tibor Menyhért na to šel ještě efektivněji. Zjistil zbytek po vydělení čtyřmi a přiřadil si ke hráči rovnou. Tedy Sever=1, Východ=2, Jih=3 a Západ=0.

Těžší situace je spočítat hru, když je pohyb proti směru hodinových ručiček, zkusíme si to představit přes tuto pomůcku.

Takto bychom si mohli představit hru pro dvacet rozdání. Hra se posouvá zvrchu dolů ve sloupci a zleva doprava. Důležitá je změna na první pozici u čtyř rozdání, je to ten pátý řádek. Prvně to byla nula (Nikdo), pak jednička (linka Sever-Jih), poté dvojka (linka Východ-Západ) a nakonec trojka (Obě linky). Takže se nám hodnota vždy přičte o jedničku po každé čtveřici, tedy k číslu rozdání přičteme celočíselnou hodnotu (uřízneme desetinnou čárku a vše od ní vpravo) po vydělení čtyřmi. Poněvadž bychom mohli dostat hodnotu vyšší než 3 (např. u čtrnáctého rozdání (mínus ona magická jednička) to je 13+3), což je 16), tak tento mezivýpočet znovu proženeme kalkulátorem a vezmeme jen zbytek po vydělení čtyřmi. To je nula a nikdo není ve hře.

Jak to však bude od 17. rozdání dále? 17. rozdání je stejné jako první atd. Takže bychom mohli zvažovat zbytek po dělení šestnácti, ale to je zbytečné. 16 je násobek čtyř.

Pojďme konkrétně k našemu 1634. rozdání? Upravíme hodnotu na řadu začínající od nuly o jedničku na 1633. Dále 1633+1633/4=2041,25 a odřízneme desetinnou část, tedy 2041. Zbytek po 2041/4 je 1. Linka Sever-Jih bude ve hře, druhá nikoliv. Výpočet je na řádku 11 a vypsání je na řádku 15 ve zdrojovém kódu.

Aby si přišli na své i sazeči, zde je drobný Python zdrojový kód (aktuální verze dvojkové řady je 2.7.4), vysázený přes Pygments [odkaz] do PNG (přímo mi to nešlo, přednastavené kódování Latin1 nebere písmena š, ž a další, a přepnout se do UTF-8 sice šlo v /pygments/formatters/img.py, ale beze změny k lepšímu), tedy přes prostředníka do HTML, přítele Pátka u Robinsona, následně převedený z HTML do PNG přes Python knihovnu wkhtmltopdf [odkaz], takové rozumné udělátko do automatizační nepohody. Zdá se mi to lepší, než klikátko typu Pearl Crescent Page Saver [odkaz]. Nakonec jsem se přiklonil ke zveřejnění HTML místo PNG kvůli velikosti na disku, zde jest uložen pod rozdava.py [], kódování textového souboru je UTF-8.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#!/usr/bin/env python
#encoding=utf-8
t=1634               # Rozdání, které mě zajímá, zde se dá dát cyklus...
rozdavajici=["Sever","Východ","Jih","Západ"]    # Konstanty rozdávající.
vehre=["Nikdo","Sever-Jih","Východ-Západ","Obě linky"]  # Konstanty hra.
try: t=int(t)                                 # Pokus o převod na číslo.
#Nebo nastala chyba, nastavuji jedničku, která se stane nultým rozdáním.
except: print "Převádím vstup na první rozdání."; t=1 # Změna při chybě.
t+=-1                                        # Úprava na pořadí od nuly.
rozdava=t%4                     # Zbytek po dělení čtyřmi (rozdávající).
je=(t+t//4)%4          # Posun o celý násobek a zbytek po dělení čtyřmi.
print "Rozdání č. "+str(t+1)                           # Co mě zajímalo.
print "Pořadí od nuly:",str(t)                         # Vnitřní úprava.
print "Rozdává",rozdavajici[rozdava]                 # Kdo tedy rozdává.
print "Hra:",vehre[je]                    # Vypiš na obrazovku výsledek.

Takto byl vysázen, do designu pygments.css [] jsem jemně ručně zasáhl.

pygmentize -f html -O encoding=utf-8,linenos=1
   -l python -o rozdava.htm rozdava.py
pygmentize -S colorful -f html >pygments.css

Pro rozdání číslo 1634 (zadané na třetím řádku zdrojáku) nám tento drobný prográmek vypíše následující čtyři řádky (python rozdava.py):

Rozdání č. 1634
Pořadí od nuly: 1633
Rozdává Východ
Hra: Sever-Jih

Teď se dá program obalit cyklem či číslo rozdání si vyžádat od uživatele při spuštění atd. Možností je celá řada, záleží na potřebě.

Pozn. Tibor Menyhért na to šel opět programátorsky efektivněji, i když hledání zbytku po vydělení 16 se nedá z hlavy téměř spočítat (oproti zbytku po vydělení 4, což se ještě jakž takž dá). Tedy posuny se opakují v každých 16 rozdáních. Na to si připravil pole a posuny upravil vnitřně, není potřeba žádných výpočtů či dopočtů, jen se zbytku po vydělení 16 přiřadí už konkrétní hodnota, 0=Žádná linka, 1=linka Sever-Jih, 2=linka Východ-Západ, 3=Obě linky.

Post Mortem: celý poklad

Nyní však již vážně. Na ZRD/ZSD soubory lze použít toto konvertítko. Získáme tím rozdání s/bez zdvihů ve formátu vhodném pro program Deal.

A z tama můžeme konvertovat dále do některého formátu ve složce /format/, případně si v Dealu či úpravou Konvertora v Pythonu doprogramujeme vlastní formát.

Já jsem si ještě navíc zkontroloval počet řádků:

Výsledek byl správný, tedy 1.048.576 rozdání v první části z celkových desíti.

Na prvním souboru mi vše sedělo. Zkusil jsem i jednoduchou optimalizaci Python kódu. Zápis velkého množství dat do souboru byl méně výhodný než malý (skoro dvojnásobně), zapnutý Indian (což mělo být zjednodušení) dávalo průměrně horší výsledek o tři čtvrtě minuty než když byl zapnutý. Načtení souboru po 23 bajtech nebo celý a pak jeho parsování nemělo vliv. Konvertor zvládl svou práci za průměrně 5 minut. Můžeme vyjádřit relativní spokojenost.

Nyní to samé přes BFC. Stáhneme si do složky s Pavlickovým konvertítkem tyto soubory (pozor, jde se po rozbalení do 450 MB, ale co to dnes je, že, taková zdravá polovina filmu CD kvality či DVDRipu):

Aktualizace 11. 6. 2013: Na přání Richarda Pavlicka byly přímé odkazy na bridžový poklad (ZIP soubory) ukryté na jeho serveru odstraněny (jeho server je přetížen i tak), detaily na ně hledejte v tomto souboru [odkaz, resp. odkaz], případně mi napište email a já vám odkazy obratem zašlu.

Soubory si rozpakujeme a podstrčíme Pavlickovu konvertítku, jenže do jakého formátu?

Pavlickův konvertor do PBN formátu to zvládl za 15 vteřin (velikost souboru 286 MB), do textového formátu za 23 vteřin (velikost souboru 532 MB). Tedy žádná miminka! Padnul by na pevném disku celý film. Zde je kompletní sumář jeho výstupních 13+1 formátů u poslední verze BFC (květen 2013):

Právě mi na disku padnulo místo velikosti DVD z prvního ZIP souboru, asi to zas smažu, poklad jeden, utopím se v tom bohatství. Černě jsou zaznačeny formáty před mým hledáním řešení a v původním konvertoru Pavlicka (verze 4.0), červeně jsou zaznačeny nové formáty zanesené během psaní tohoto článku (verze 4.3), zeleně pak poslední zásahy autora z 11. 6. 2013 (verze 4.4).

Subject: BFC 4.3
Hi Pavel,
You must be my project manager. :) Download the latest BFC (4.3) which now includes DDline format. I couldn't find a standard file extension for it, so I chose DDL (my Type I because D and L are taken). I also revised the table in BFC Main per your suggestion.
Let me know if the DDL works for you. (I tested it with my 10 MB database, back and forth, without error.)
-Richard

Můžeme si povšimnout dalších vlastních formátů Richarda Pavlicka, RBN a RBX [odkaz]. Přikládám vzorek pro první rozdání, out.rbn [] a out.rbx [], velikost je 146 a 143 bajtů na rozdání. Jsou tedy lidsky čitelné a nejsou zdaleka tak optimalizované.

Program Deal neměl ani navolenou příponu, tak ji Pavlicek zavedl (DDL) a o tom jsem s radostí napsal Thomasi Andrewsovi. Krásně se to plete s DLL, což je také knihovna, ale pro programátory.

Spuštění PY nebo PYC nehrálo v rychlosti roli, soubor jsem získal překompilováním (python kompiluj.py) následujícího uloženého ve zvláštním souboru kompiluj.py []:

Co se člověk všechno nenaučí. Pro zájemce zde je více informací o kompilování [odkaz]. Časy běhu jsem získal pomocí Linuxového programu time [man] takto:

kde za _ jsem postupně dával písmenka (t)xt, (r)bn, rb(x), (l)in, (p)bn, (e)ml, re(c), (d)at, (a)sc , (g)dd, ddl (i), d(u)p, ppl (b), (z)rd, z(s)d a (h)tm. Je zde vidět, že jsem na CygWinu, míchám spouštění Windows a Linux programů, dnes se to už tak striktně nebere.

Pro nás ostatní a díky Pavlickovi existuje tato snadnější cesta, neb i on doznal, že je to těžké (formát pro vyřešená symetrická rozdání jsem pro účely tohoto článku vzdal).

Nejjednodušší vlastně byla jen kontrola integrity binárně načteného souboru pomocí součtu hexadecimálních čísel úseků, v našem případě tedy bajtů seřazených od konce, kdy úseky sčítanců tvořilo 32 bitů (čtyři bajty). Ty bajty musely být přeházené, protože jedno rozdání tvoří 23 bajtů a toto číslo není dělitelné čtyřmi, takže na pořadí bajtů záleží neb se ty čtveřice lomí.

Co víc si člověk může přát? Na mé návrhy (tyto dva hádankářské binární formáty z BIN na ZRD+ZSD v prvním kole), spíš stavy zoufání, rozšířil Pavlicek svůj konvertor, v druhém kole i o formát pro program Deal se zkratkou i [odkaz] a nově zavedenou příponou DDL. Bohužel můj Velký konvertor byl překonán, konverze první části RP01.ZRD do DDL trvala 10 vteřin, zatímco já to zpracovával 5 minut (to je třista vteřin, tedy třicetkrát pomalejší – co jeden dělá jeden celý den, druhý dělá celý měsíc), Velký konvertor se tímto degraduje na Mikrokonvertor! Se svým mikrokonvertítkem jsem se pod těchto pět minut nikdy nedostal, víc do optimalizace Python kódu nevidím. Je alespoň stále co zlepšovat... Pro tohle piráti (nechci zrovna napsat pyrát jako python rat, volně přeloženo jako potkaní/krysí krajta, krajtí potkan/krysa či krajta+krysa/potkat, vyberte si...), chtěl jsem říci programátoři, žijí a umírají!

Když tedy vyzkoušíme na první části Pavlickova archivu:

Zjistíme, že jsou naše výstupy identické na úrovni bitů. Z vědeckého pohledu uvažování bychom měli též ověřit, jestli Pavlicek nepoužívá stejnou DD knihovnu jako program Deal [odkaz], tedy DDS knihovnu Bo Haglunda (je to C++ zdrojový kód a měl dříve přes 100 tisíc znaků; odkaz, resp. knihovny jsou zde, v Linuxovém repozitáři pod klíčovým slovem DDS jsem tyto zdrojové kódy neobjevil). Pokud ano, pak bychom srovnávali výsledky vzniklé ze stejného zdroje (ať už by tam byly chyby či nikoliv) a tento článeček můžeme hodit do koše. Pryč s ním! Kdyby tam totiž byla chyba, tak se objeví na obou výstupech a my bychom je prohlásili oba za správné, neb by byly výstupy identické, ale my bychom je chybně považovali za nezávislé. Tref by člověka trefil!

Zde je ukázka běžícího DDS v Linuxu:

Od jedné až po rozdání 4. Soubor je uložen v /usr/share/doc/dds/examples/. Případně po rozpakování test.gib.gz v tom samém adresáři:

DD řešení je v posledním řádku u jednotlivých rozdání.

Poněvadž mám roky v hlavě tajný nápad na měření obtížnosti bridžového rozdání (jistá vize to je, reálné to asi bohužel není, ani Bo Haglund to růžově nevidí), tak k tomu byly potřeba zdrojové kódy, aby se dalo dostat do celého rozhodovacího stromu a mezivýpočtů. Ty byly právě u Aleaxe [odkaz], po rozbalení dds10.zip [odkaz] se to z C++ zdrojových kódů sice pohlo:

Ale stejně jsem s tím nepohnul... To chce programátora. Poslední verze zdrojových kódů [odkaz] z března 2013 má už přes 200 tisíc znaků, v tom se nedá vrtat, ve stavu zoufání píši autorovi, jestli by mi nepomohl, nezpřístupnil mezivýpočty či nějakou formu ladění (to má ve zdrojovém kódu připravené, ale je to tam vypnuté). Tak poctivě jsem rekurzi či nějaký alternativní postup nestudoval. Bohužel po letech docházím k závěru, že se dá měřit časová náročnost díky rozhodovacímu stromu, ale na měření obtížnosti z karetního pohledu to nebude.

Nu, užijte si 10.485.760 zanalyzovaných rozdání! Ještě píši Pavlickovi, jestli by nepřidal do svého BFC konvertoru originální Ginsbergův formát s příponou ASC (navrhl jsem zkratku písmene a, neb písmena s a c má už zabraná), z historických důvodů, ten se od DDL formátu sice moc neliší, ale identický není...

Aktualizováno 11. 6. 2013: Verze BFC 4.4 je na světě! [web, poznámky, program]

Subject: BFC 4.4
Hi Pavel,
I finally got around to adding the two Ginsberg DD formats (ASC,BIN). The problem was deciding on file extensions, as I had used .ASC for BFC's template files, and I use .BIN for many things (as does the world). I decided to rename BFC'S template files to .BFC (that makes sense) but .BIN was too valuable for Ginsberg's stupid format (26 bytes when only 23 are necessary)... so I christened his binary files as .GDD = Ginsberg double-dummy or Type G. The ASCII format is .ASC or Type A.
-Richard

R.I.P. pro ty, kteří umřeli při četbě tohoto příspěvku. Autor příspěvku se jen za přispění Daidalose, samotného tvůrce, dostal z tohoto labyrintu...

P.S. Nyní mohu klidně umřít, s pokladem v rukách...

Děkuji Tiboru Menyhértovi za připomínky, dle možností jsem je zapracoval. Člověk se na tom bridžovém ostrově necítí alespoň tak sám.