-
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
From: Piotr Chamera <p...@p...onet.pl>
Newsgroups: pl.comp.programming
Subject: Re: Taki problem programistyczny...
Date: Thu, 23 Feb 2012 08:55:59 +0100
Organization: "Portal Gazeta.pl -> http://www.gazeta.pl"
Lines: 143
Message-ID: <ji4rek$3st$1@inews.gazeta.pl>
References: <m...@4...com>
<ji3aku$569$1@inews.gazeta.pl> <ji3f8b$jkc$1@inews.gazeta.pl>
<ji3tf7$3mn$1@news.icpnet.pl>
NNTP-Posting-Host: public40653.xdsl.centertel.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: inews.gazeta.pl 1329983764 3997 79.163.158.205 (23 Feb 2012 07:56:04 GMT)
X-Complaints-To: u...@a...pl
NNTP-Posting-Date: Thu, 23 Feb 2012 07:56:04 +0000 (UTC)
X-User: p71a
In-Reply-To: <ji3tf7$3mn$1@news.icpnet.pl>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
Xref: news-archive.icm.edu.pl pl.comp.programming:195649
[ ukryj nagłówki ]W dniu 2012-02-23 00:24, n...@m...invalid pisze:
> W dniu 22.02.2012 r. 20:21, Piotr Chamera pisze:
>> W dniu 2012-02-22 19:03, Piotr Chamera pisze:
>>> W dniu 2012-02-21 22:52, A.L. pisze:
>>>> Od niejakiego czasu zaprzata mnie nastepujacy problem:
>>>>
>>>> Dany jest skierowany graf acykliczny. Jak wiadomo, taki graf mozna
>>>> posortowac topologicznie. Takich porzadkow topologicznych jest
>>>> olbrzymia ilosc.
>>>>
>>>> I teraz problem:
>>>>
>>>> 1. W praktycznych zadaniach ten graf moze byc bardzo duzy - setki
>>>> tysiecy wezlow
>>>> 2. Graf nie musi byc spojny
>>>> 3. Dane jest uporzadkowanie topologiczne, jedno z mozliwych
>>>> 4. Chce sie zmienic polozenie N wezlow w tym porzadku, gdzie N jest
>>>> nieduze (kilka). Wezly sa wybrane przypadkowo
>>>>
>>>> Pytanie:
>>>>
>>>> 1. Czy ta zmiana polozenia N wezlow narusza uporzadkowanie
>>>> topologiczne, to znaczy czy po przestawieniu otrzymamy znow porzadek
>>>> topologiczny czy nie
>>>> 2. Takie sprawdzenie musi byc EXTREMALNIE wydajne, bo powtarzane jest
>>>> miliony razy, a program musi sie wykonywac bardzo szybko.
>>>>
>>>> Oczywiscie, "brute force" jest trywialne. Ale "nie brute force"
>>>> niekoniecznie jest trywialne. Tyle ze "brute force" strasznie dlugo
>>>> sie wykonuje, nawet przy maksymalnej optymalizacji kodu
>>>>
>>>> Rzecz potrzebna w pewnych algorytmach "constraint programming"
>>>> zwiazanymi z planowaniem kalendarzowym i routingiem. Dopuszczalny jest
>>>> "preprocessing" grafu w celu utworzenia struktur danych
>>>> przyspieszajacych proces. Pamiec nie jest ograniczeniem.
>>>>
>>>> Jak ktos nie ma nad czym myslec, to proponuje nad tym
>>>>
>>>> A.L.
>>>
>>> 1. Każdy węzeł grafu reprezentujemy tak, że znane są listy jego
>>> poprzedników i następników w grafie.
>>>
>>> 2. Znakujemy węzły rosnąco liczbami wymiernymi wg kolejności w
>>> wyjściowym porządku (to można zrobić raz dla wielu kolejnych
>>> przekształceń, może być potrzeba dokładnej arytmetyki).
> 1: 1/2; 2: 2/3; 3: 3/4; ... ? Co to daje, mogę prosić o objaśnienie?
Poniżej przedstawiam mój tok myślenia, może się gdzieś pomyliłem, jeśli
tak, to proszę o wskazanie błędów.
Załóżmy tak graf reprezentowany jako lista węzłów,
gdzie węzeł to (,,nazwa węzła" (lista następników) (lista poprzedników))
przykładowy graf: ((a (b c) ())
(b (c d) (a))
(c () (a b))
(d () (b)
jest w tej chwili posortowany topologicznie w kolejności a b c d.
numerujemy go liczbami naturalnymi (dla uproszczenia)
(a 1) (b 2) (c 3) (d 4)
zauważmy, że wszystkie poprzedniki dowolnego węzła mają znakowanie
mniejsze od niego, a następniki większe, czyli mamy prosty sposób
sprawdzenia, czy dowolny inny węzeł jest poprzednikiem czy następnikiem
danego (lub jest w części grafu niezależnej od danego węzła).
W prostym przypadku pojedynczego węzła: jeśli przeniesiemy węzeł w_x
wstecz przed w_y i taka zmiana zachowuje sortowanie, to nadal wszystkie
poprzedniki w_x powinny mieć znakowanie mniejsze od niego, bo jeśli nie
to w nowym porządku istnieje krawędź z wierzchołka, który leży teraz
pomiędzy w_x a w_y do w_x (czyli wstecz, wbrew porządkowi).
Przy przenoszeniu pojedynczego węzła w przód należy sprawdzić jego
następniki, czy nie mają teraz numeracji mniejszej od niego.
Wychodzi mi, że w ogólnym przypadku przenoszenia N węzłów trzeba
(1) sprawdzić następniki i poprzedniki wszystkich przenoszonych węzłów
i (2) czy same te węzły nadal są w porządku topologicznym (choć to może
wynikać z (1) - nie przemyślałem tego).
Przykłady:
1) po przeniesieniu węzła c przed b mamy
(a 1) (c 3/2) (b 2) (d 4)
w zbiorze poprzedników (c 3/2) mamy (a 1) i (b 2) co wskazuje na
istnienie krawędzi z b do c, która w nowym porządku wskazuje wstecz.
Przy przenoszeniu wstecz w zbiorze następników nic się nie zmieni.
2) po przeniesieniu węzła c poza d mamy
(a 1) (b 2) (d 4) (c 5)
w zbiorze następników (c 5) był pusty, więc nic się nie mogło zepsuć.
Przy przenoszeniu wprzód w zbiorze poprzedników nic się nie zmieni.
3) po przeniesieniu węzła a poza d mamy
(b 2) (c 3) (d 4) (a 10)
w zbiorze następników (a 10) mamy (b 2) i (c 3) co wskazuje na istnienie
teraz 2 krawędzi wstecz (czyli znów zepsuliśmy porządek).
Przy przenoszeniu wprzód w zbiorze poprzedników nic się nie zmieni.
>
>>> 3. Typujemy N wierzchołków do zmiany miejsca.
>>>
>>> 4. Dla każdego z N wierzchołków wyliczamy nowe znakowanie jako liczbę
>>> pośrednią między poprzednikiem i następnikiem w docelowym porządku (np
>>> średnia arytmetyczna ze znakowań poprzednika i następnika w porządku
>>> docelowym).
>>>
>>> 5. Dla każdego z N wierzchołków bierzemy listę jego poprzedników w
>>> grafie.
>>>
>>> 5a Dla każdego poprzednika z powyższej listy sprawdzamy, czy na liście
>>> jego następników nie ma wierzchołka ze znakowaniem mniejszym niż jego
>>> własne.
>>
>> Mam problem z 5 punktem, to czy powinniśmy sprawdzić poprzedniki czy
>> następniki zależy od kierunku przesunięcia węzła w grafie.
>> Jeśli dany węzeł wędruje ,,do tyłu" względem wyjściowego porządku trzeba
>> sprawdzić następniki jego poprzedników. Jeśli ,,do przodu", to należy
>> porównać poprzedniki jego następników.
>>
>> Ale być może bredzę - dziś już zmęczony jestem... może jest jeszcze
>> więcej możliwych przypadków...
>>
>>> Jeśli to zadziała, to w najgorszym wypadku mamy do sprawdzenia N x m x o
>>> porównań, gdzie m to max liczba poprzedników, a o max liczba następników
>>> węzła w zbiorze węzłów N.
>>>
>>> Rysowałem sobie to na kartce, mogłem jakiś przypadek pominąć lub źle
>>> zrozumieć zadanie...
>
Następne wpisy z tego wątku
- 23.02.12 10:47 Piotr Chamera
- 23.02.12 19:23 A.L.
- 23.02.12 23:14 Piotr Chamera
- 24.02.12 14:01 A.L.
- 24.02.12 16:37 Piotr Chamera
Najnowsze wątki z tej grupy
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
Najnowsze wątki
- 2024-11-21 Re: Dla mr. J.F`a, Trybuna i Wiesiaczka którzy "troszczą" się o państwowe i u których 0 pragmatyzmu
- 2024-11-21 Re: Dla mr. J.F`a, Trybuna i Wiesiaczka którzy "troszczą" się o państwowe i u których 0 pragmatyzmu
- 2024-11-21 Re: Dla mr. J.F`a, Trybuna i Wiesiaczka którzy "troszczą" się o państwowe i u których 0 pragmatyzmu
- 2024-11-20 "betamaxy" i inne voip-y dzisiaj
- 2024-11-21 Strach się bać
- 2024-11-21 Koniec smrodów
- 2024-11-20 Krematorium
- 2024-11-20 Taki tam szkolny problem...
- 2024-11-20 LIR2032 a ML2032
- 2024-11-20 SmartWatch Multimetr bezprzewodowy
- 2024-11-21 Środa Wielkopolska => Konsultant SAP <=
- 2024-11-21 Łódź => Spedytor Międzynarodowy <=
- 2024-11-21 Wrocław => Inżynier bezpieczeństwa aplikacji <=
- 2024-11-21 Kraków => Lead Java EE Developer <=
- 2024-11-21 Karlino => Konsultant wewnętrzny SAP (FI/CO) <=