Dotaz: Grafové algoritmy - najkratsia cesta vs. vrcholmy

[rss]

Mám orientovaný graf s ohodnotenými hranamy a chcem prejsť všetky vrcholy tak aby výsledná cesta bola najkratšia (súčet hodnôt hrán bol najmenší). Neviem aký algoritmus použiť.

Zo školy si už nič nepamätám tak som si prešiel pár základných grafových algoritmov ale zdá sa mi že tento problém nepasuje na ani jeden algoritmus (Obchodný cestujúca, Dijkstrov, Borúvkuv, Janikov, Ford-Fulkernson,..).

Obchodný cestujúci to nieje, tam je podmienka že štart a cieľ musí byť v tom istom vrchole a každý vrchol sa môže prejsť iba raz. Toto mi je jedno kde je štart a cieľ a tiež mi je jedno koľkokrát sa cez vrchol prejde...

Čínsky poštár to tiež nieje, pretože tam ide o to aby sa každá hrana prešla iba raz a to mi je jedno...

Takto som postupne vylúčil všetky algoritmy a nemám nič

Odpovědi

[frr]

Řešíte akademické cvičení, nebo praktickou úlohu? Pokud jde o praktickou úlohu, tak se nestyďte a prostě odněkud začněte programovat

Nejvíc práce Vám dá podle mého "infrastruktura" - implementace datových struktur, loadování dat z disku, nějaký výstup (uživatelské rozhraní) - budete tu topologii skutečně graficky zobrazovat (případně i zadávat)? Až budete mít tohle hotovo, pak si můžete hrát s heuristikou algoritmu - ala "robot Karel"

Pokud by hrany byly rovnocenné, asi bych začal tím, že bych se snažil procházet graf "od buka do buka" (jako když na lyžích křižujete sjezdovku). Tj. začal bych třeba "jdi do sousedního uzlu, který je nejvíc vlevo z dosud nenavštívených" - a když bych narazil na koncový uzel (žádný další nenavštívený uzel), zkusil bych pátrat po nejbližším dalším dosud nenavštíveném uzlu (pátral bych 1,2,3... hopy okolo) nebo bych si pamatoval, ve kterém uzlu jsem naposledy zaznamenal víc než jednu možnost, kam se vydat, a tam bych se vrátil. A pokračoval bych doprava. Anebo dál doleva, ale pak by to nebylo "cik cak", ale "zvenčí dovnitř" (resp. zevnitř ven, podle toho kde jste začal). V dalším kroku bych mohl zkusit zohlednit v rozhodování cenu další hrany (nějakou váhou). Nebo bych mohl zkusit nějakou "shlukovou analýzu blízkého okolí (N hopů)" - abych si zbytečně nevytvářel "dlouhé slepé větve", nebo abych elegantně "vyčistil malé lokální smyčky bez únikových cest", třeba i s lokální dooptimalizací hrubou silou (všechny možnosti). Nebo bych v "blízkém okolí" detekoval cykly v grafu a vyhýbal bych se dražším hranám... Zkuste přemýšlet, jak byste problém řešil selským rozumem (za volantem s mapou v ruce) - a algoritmus zapsat jako program.

Tak mě napadá: je to rovinný (2D) graf, nebo amorfní chumel? (při zobrazení v 2D se hrany kříží a vedou klidně napříč celým grafem) Tam by pak neměly smysl pojmy "napravo a nalevo"

Nemám v oboru formální vzdělání - nicméně mám představu, že tohle nemá nějaké "jediné správné a přímo spočítatelné" řešení. Problém typu "obchodní cestující" má k Vašemu zadání skutečně nejblíž. Patrně velmi přesně Vaše zadání odpovídá praktickému problému různých kurýrních služeb (pošta, DHL/UPS/TNT/DPD/PPL/GP...). Četl jsem, že to někdo zkouší třeba pomocí genetických algoritmů. Taky mi to připomíná některá "témata" Xscreensaveru

[frr]

Aha, on je orientovaný Otrava...

[frr]

Orientovaný nebo ne, napadlo mě začít nějakou shlukovou analýzou. Najít jakási "těžiště" a k nim "gravitovat".

Pokud je orientovaný, možná bych se snažil napřed najít 1) uzly, odkud není cesty ven nebo kde není cesty dovnitř a 2) uzavřené oblasti, odkud není cesty ven nebo kde není cesty dovniř. To je základ pro posouzení, zda vůbec máte šanci všecky uzly projít, případně kde začít a kde skončit - a do kterých uzlů či oblastí se lze vrátit.

Takový obchodní cestující, kde všecky cesty jsou jednosměrky?

[petr_p]

Problém má určitou složitost. Takže sebelepší algoritmus nebude lepší, než je třída problému. Pokud je problém NP-úplný, tak na polynomickou složitost algoritmu zapoměňte.

Samozřejmě, když si odpostíme podmínku optimálnosti, tak se dají vymyslet heuristiky, které občas trochu pomůžou.

[Radek Miček]

Váš problém je NP-úplný. Pokud bude vstupem úplný graf, kde platí trojúhelníková nerovnost, tak se v optimálním sledu neopakují vrcholy, tudíž je to cesta, a tudíž je váš problém TSP pro cesty v grafu s trojúhelníkovou nerovností, který je NP-úplný.

[Radek Miček]

Intuitivní důkaz

[Radek Miček]

Řešení lze kódovat jako permutace vrcholů grafu. Tudíž bych mezi permutacemi hledal takovou, která reprezentuje nejlepší řešení.

Napřed bych spočítal tranzitivní uzávěr grafu. Pak bych vybral vrcholy, co v té permutaci mohou být první, druhé, třetí, čtvrté... Zvolil bych první vrchol a podíval se, který vrchol může být další, zvolil ho... Dále bych průběžně propagoval důsledky svých voleb směrem dolů, abych případný problém odhalil co nejdříve (jako v CSP). Stejně tak je možné testovat délku cesty průbežně.

[stativ]

Proč si vyloučil Borůvku a Jarníka? Mě se zdá, že je to přesně to, co potřebuješ (minimální kostra).

[stativ]

Aha, on je orientovaný, to jsem krapet přehlédl.

[rss]

Je to čisto praktický problém, nie akademický...

Ide o to, že mám v krajine okolo jednej dediny pár zaujímavých miest všeliako poprepájaných cestamy, cestičkamy, stezkamy, ktoré by som si chcel v lete na bicykli pozrieť. Je to presne 15 bodov takže mi je jedno akú bude mať algoritmus výpočtovú zložitosť (ak nebude NP-úplný to by už boli asi bilióny potenciálnych ciest). Samozrejme toto sa dá určiť intuatívne z hlavy pohľadom do mapy ale kež už som kedysi absolvoval predmet Diskrétna matematika tak mi to dalo chrobáka do hlavy

Tak som si určil, že tie body v krajine sú vrcholy grafu a hrany medzi nimi sú rôzne možné cesty ohodnotené počtom kilometrov medzi nimi. Lenže potom ma napadlo, že kritérium vzdialenosti nieje jediné, podľa ktorého sa človek v teréne rozhoduje. Tento algoritmus by ma totiž napríklad viedol z hrebeňa dole do doliny lebo je tam blízky bod a potom naspäť hore na hrebeň na nejaký ďalší bod, ktorý je trebars len o kúsok ďalej. Lenže človek by logicky dal prednosť prejsť najprv 2 body hore na hrebeni v jednej nadmorskej výške aj keď sú trebars dvojnásobne vzdialené ako bod v doline. A až potom by zišiel dole aby v kuse nechodil hore-dole čo by ma na biku vyčerpalo

Preto som z grafu urobil digraf (orientovaný graf) aby som smer AB (dolekopcom) mohol ohodniť inak ako opačný smer BA (horekopcom). Takto môžem hrane z bodu A do B dať hodnotu 4 (4 km) a naopak z B do A dať 6 (4 km + 2 ako penalizácia že to je hore kopcom). Túto penalizáciu budem dávať len tak subjektívne z hlavy podľa sklonu kopca. Určite by sa dal nájsť aj nejaký algoritmus ktorý by tu penalizáciu vypočítaval automaticky ako rozdiel nadmorskej výšky dvoch bodov...Ďalšia penalizácia môže byť či to je pekná/rozbitá cesta, atraktívne/neatraktívne okolie...No a výsledok je že mám ako som písal v prvom príspevku orientovaný graf s hranami ohodnotenými nejakými hodnotamy a chcem prejsť v grafe všetky vrcholy s najmenšou "vzdialenosťou" (v uvodzovkách pretože ako som písal, ohodnotenie hrán nevyjadruje len vzdialenosť).

Žiadne ďalšie obmedzenia niesu. Začať a skončiť môžem kde chcem. Ak to je výhodné tak vrcholom grafu môžem prejsť aj viackrát (ale minimálne raz). Po rovnakých hranách môžem prechádzať tiež viackrát, po nevýhodných hranách nemusím ísť ani raz...

[Radek Miček]

Když to je jen 15 vrcholů a cesta vede z každého do každého tak bych to řešil takto:

Spočítal bych nejkratší cesty z každého vrcholu do každého. Protože je řešení (průchod vrcholy) reprezentován permutací, tak lze projít všech n! permutací, u každé si zapamatovat skóre a pak vydat tu nejlepší. Jelikož 15! už je celkem velké číslo, tak bych to těch patnáct prvků rozdělil všemi možnými způsoby (6435) na 2 části (7 a 8 vrcholů). V první části bych našel nejlepší (=nejlevnější) permutaci, která končí číslem 1, nejlepší, která končí číslem 2, ... Ve druhé části bych našel nejlepší, která začíná číslem 1, nejlepší začínající číslem 2, ... Pak bych tyto nejlepší permutace ze 7 a 8 prvků zkusil různě pospojovat a zapamatoval bych si nejlepší řešení. Takto jsem zpracoval jedno rozdělení z 6435 a 6434 mi ještě zbývá.

Celé to pak lze řešit obdobně metodou rozděl a panuj. Prostě se ta čísla v permutaci rozdělí na 2 části všemi možnými způsoby a pak tyto dvě části zase spojuji.

[mc_bizon]

6453 * 7! * 8 ! = 15!. Žiadnym rozdeľovaním si nepomôžeš.

[Radek Miček]

Jenže já mám zhruba 6435 * (7! + 8! + čas na spojení).

[frr]

Chtělo by to nějaký algoritmus, který by poskládal trasy tak, aby člověk jel pořád jenom skopce dolů

[FooBar]

Bagr Z., Buldozer C.A.T. Nekonecny presun zeminy na trase cyklisty. In Proceedings of the 99th ACM Symposium of Algorithms and Heavy Machinery, page 101, November 2010. ?;)

[mc_bizon]

http://en.wikipedia.org/wiki/Edmonds's_algorithm

Čítal som len ten prvý odstavec, ale vyzerá to byť to čo potrebuješ

[:::]

tak jestli je to 15 bodu tak mas 15! = 1.3e12 permutaci takze na dnestnich pocitacich by se dali projit i vsechny... Teda pokud ti nevadi na vysledek par minut pockat.

Jinak pokud nepotrebujes optimalni reseni, ale staci ti nejaky "dostatecne dobry" tak bych na to sel nejak takhle:

for i in 1..1000: # or another big number instead of 1000
        x = random_permutation()
        if length(x) < best_length:
                best_x = x;
                best_length = length(x)