Vianoce v ITnetwork sú tu! Dobí si teraz kredity a získaj až 80 % extra kreditov na e-learningové kurzy ZADARMO. Zisti viac.
Hľadáme nové posily do ITnetwork tímu. Pozri sa na voľné pozície a pridaj sa k najagilnejšej firme na trhu - Viac informácií.

Vzájomný zápočet

Program vzájomného zápočtu mal vyhodnotiť, čo všetko je možné z balíka nerealizovaných položiek zaplatiť bez vloženia finančných prostriedkov - takzvanú vzájomnú kompenzáciou pohľadávok. Úloha zdanlivo jednoduchý, ale pri bližšom pohľade na vec zistíte, že sa jedná o veľmi zložitý problém. Keď sa jedná o vzájomnej dlhy medzi dvoma dlžníkmi, tak to vie vyriešiť malé dieťa v základnej škole. Ako ale pribúdajú účastníci, tak geometrickým radom rastú väzby medzi nimi a vynára sa otázka, ktorej cesty by sa mali použiť, aby sa dosiahlo čo najväčšieho efektu.

Ukázalo sa, že klasické "vedecko-matematické" postupy, ktoré sa vtedy snažili riešitelia použiť, zďaleka nedosahujú očakávané výsledky. Úloha vtedy riešila skupina "ekonómov" okolo p. Václava Klausa a p. Rudlovčáka, ktorí v tom čase pracovali v Štátnej banke. Ja som v tej dobe tiež pracoval v danej inštitúcii, ale na rozdiel od nich som sa nezaoberal ekonomickými odhady, ale som zodpovedal za to, aby denný spracovanie prebehlo v poriadku a ráno boli v celej republike k dispozícii korektné výpisy z účtov. Musím sa priznať, že kým ma neupozornili, aby som sa o túto problematiku nezaujímal, tak som ju skutočne nevenoval pozornosť. Potom mi to ale nedalo a začal som o nej premýšľať. Nepáčili sa mi spomínané vedecké metódy a stále som cítil, že tomu niečo chýba, skrátka že to nie je ono.

A jedného dňa ma napadlo, že by sa to dalo riešiť úplne inak. Nedalo mi to a skúsil som si to napísať. Keď sa mi to podarilo konečne odladiť, išiel som sa opýtať, či nešmýkali čas v počítači, pretože výpočet bol veľmi rýchly. Človek si musí ale uvedomiť, že v živote pri realizácii nestojíte len pred technickými problémami, ale aj pred problémami z oblasti spoločnosti. Proti mne stála skupina, ktorá svojim ďalším spoločenským vývojom jasne preukázala, že o svoje ciele hrá tvrdo. Dať to len tak na stôl, jednoducho nešlo a preto som svoje riešenie podal ako zlepšovací návrh, proti v tej dobe už ich hotovému riešenie. Tým som získal zákonné právo, že museli porovnať svoje už hotové riešenia s mojím. Porovnanie bolo jednoduché. Ich riešenie počítalo 8 hodín a uvoľnilo z daného balíka cca 1 miliardu. Moje riešenie pracovalo 30 sa uvoľnilo z rovnakého balíka cca 2 miliardy.

Realizácie

Na tomto príklade je vidieť, že "programovací technika" môže všeličo, ale najdôležitejšie je pochopiť čo a prečo počítať. A teraz, keď už vieme zhruba o čo sa vlastne jednalo, tak sa pozrieme na to, ako to bolo vykonané. Riešenie vychádzalo z toho, že namiesto toho, aby sa počítalo, čo možno zaplatiť, tak sa počítalo, čo sa nemá, respektíve je nevhodné zaplatiť. Keď sa pokúšate vypočítať, čo máte zaplatiť, tak vlastne neviete, kde začať a kam pokračovať. Pri hľadaní toho čo sa nemá realizovať, môžete inicializáciou previesť problém do stavu, keď je toto jasné. Preto prvý bol inicializačné krok pre nastavenie situácie. Ten krok spočíval v tom, že najprv sa všetko zaúčtovávalo. Tým sa ale niektoré účty dostali do debetu a iné do kreditu. Predstavíme Ak si situáciu, že po tomto kroku by všetky účty až na dva boli na nule, potom existuje jedna platba medzi týmito dvoma účtami, ktorá spôsobí to, že daný účet bude v debetu a ten druhý v kreditu. Takže stačí ju odstrániť a máme najefektívnejšie riešenie a dá sa povedať, že skoro bez počítania.

Problém je to, že platba nemusí byť iba priamo medzi týmito účtami, ale môže prechádzať cez niekoľko ďalších ako transakcie in / out. Problém sa vyrieši rekurzívne funkciou, ktorá odstraňuje platby medzi kreditnými a debetnými účty. Ako parameter má počet meziúčtů, cez ktoré môže daný vzťah prechádzať. V prvom kole sa nastavil počet meziúčtů na nulu, a odstránili sa všetky položky medzi účtami, kde jeden bol v debetu a druhý v kreditu a medzi nimi nebol žiadny ďalší. Ak sa tým všetky účty nedostali na nulu, zdvihol sa počet meziúčtů o jeden a podprogram zavolal rekurzívne sám seba. Tak sa postupovalo, kým neboli všetky účty na nule, alebo sa nevyčerpal maximálny počet vnorenia. To bolo nastavené na 10, ale k vyčerpaniu nikdy nedošlo.

Toto riešenie okrem veľmi rýchleho a efektívneho výpočtu, vykonalo aj analýzu, koľko by šlo uvoľniť pri úveroch na správne miesto. Každá dávka vyradená pri zodpovedajúcom vnorenia, svojím objemom a vyradenú sumou naznačovala, koľko by sa uvoľnilo, keby sa poskytol úver v tejto výške konkrétnom dlžníkom. Čím väčšia vnorenia, tým bola väčšia efektivita zníženie objemu dlhov. Tieto informácie však neboli nikdy využité a k úverovania sa nepristúpilo.

Výsledok

Pre predstavu o rozsahoch problematiky a dopadov vzájomného zápočtu, môžem uviesť, že posledný spracovanie dát bolo ešte po rozdelení Československa na Českú a Slovenskú republiku. Výsledky spracovania vtedy hlásili v rozhlase, a boli nasledujúce: Predstavíme Ak si problém ako mapu, dlžníkmi ako mestá a sčítaného dlhy ako cestu medzi nimi, tak sa jednalo o 5000 miest, medzi nimi 170 000 sčítaných dlhov ako ciest. Spracovanie trvalo 5 minút a uvoľnenie malo hodnotu vyše 8 miliárd.

Ešte by som rád povedal, že okrem vhodného algoritmu výpočtu, je potrebné vytvoriť tiež technické podmienky pre realizáciu. Prvou bolo to, že bolo potrebné vykonať dostatočnú integráciu dát, aby počet väzieb zodpovedal skutočne nutnému minime. Preto boli jednotlivé položky so zhodnými účty (debet + kredit) sčítané do jednej. Z vyššie uvedených výsledkov je zrejmé, že aj po sčítaní všetkých čiastkových položiek medzi dvoma partnermi do jedinej, ich bolo stále ešte 170 000. Druhé čo bolo nutné vyriešiť, bola štruktúra uloženie dát v pamäti a manažment výmeny dát medzi pamäťou počítača a diskovým nosičom tak , aby sa toto nestalo úzkym profilom pri spracovaní. A pretože na konci bolo nutné výsledky spätne vyjadriť v detailných položkách, tak bolo nutné vnútiť deagregační podmienky užívateľmi. To znamená, že podľa vypočítané čiastky medzi dvoma účtami sa postupne zo záväzného poradí platieb, ktoré boli zoskupované do jednej, uvoľňovali jednotlivé platby s tým, že pri poslednej možné platby bola vykonaná iba čiastočná úhrada vo výške, ktorá bola ešte k dispozícii. Inak by sa celý výsledok rozbil a prestal by byť účtovne správny. To ale nebol problém, pretože čiastočné úhrady už boli v tom čase podporované a dá sa povedať i bežné.


 

Všetky články v sekcii
Články nielen o programovaní
Článok pre vás napísal Petr Vocel
Avatar
Užívateľské hodnotenie:
Ešte nikto nehodnotil, buď prvý!
Autor se méně soustředí na nástroje a pozornost věnuje více tomu jak dostat funkčnost reaálného světa do počítače.
Aktivity