Dotaz: Hledání nejdelší symetrické části řetežce

[Arses]

Zdravim, potřeboval bych poradit s tímto problémem, jak najít nejdelší symetrickou část (třeba 1235555321) a podobně. Potřebuju co nejméně časově náročnou verzi, napadlo mě jenom toto:

.
.
delka = 1;
for (i = 0; i < n-1; i++)
   for (j = i+1; j < n; j++) {
      sym = 1;
      for (k = 0; i+k < j-k; k++)
         of (a[i+k] != a[j+k])
             sym = 0;
      if (sym && (j-i+1 > delka))
         delka = j-i+1;
    }
.
.
.

A to je časově poměrně dost náročný

Jinak n je délka řetězce a délka je velikost onoho nejdelšího úseku... ostatní je jasný bych řekl...

Díky moc za každou radu

Odpovědi

[Arses]

Ještě dodám, že nezáleží na jazyku, jde mi čistě jen o ten algoritmus, C sem vzal jenom jako příklad...

[Michal Kubeček]

To je domácí úkol nebo nějaká soutěž?

[Arses]

Ani jedno, domácí úkol byl napsat to... to sem udělal, ale nejsem s tim spokojenej....

[Matyáš Dvořák]

asi bych pouzil neco ve stylu grep '^\(.\)\(.\).\2\1$' soubor

[moira]

http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/Suffix/

Zacatek + odstavecek o hledani palindromu. Muzete dosahnout narocnost O(n) ;)

[Arses]

Díky moc, jdu se tim prokousat

[Hynek (Pichi) Vychodil]

#include <stdio.h>

int main(int argc, char **argv) {
	char *start, *end, *lpos, *i, *j;
	int lhalf = 0;
	if (argc >=1 ) return 1;
	start = argv[1];
	for(end = start; *end; end++);
	for(lpos = i = start; i < end - lhalf; i++) {
		for(j = i; j>=start && (i + 1 + (i - j) < end) && *j == *(i+1+(i-j)); j--);
		if( i-j > lhalf) {
			lhalf = i-j;
			lpos = j+1;
		};
	};
	if(lhalf) {
		*(lpos + 2*lhalf) = 0;
		printf("%s\n", lpos);
		return 0;
	} else {
		return 1;
	}
}

[Hynek (Pichi) Vychodil]

Zatr. Samozřejmě tam má být

	if (argc <=1 ) return 1;

[Hynek (Pichi) Vychodil]

Jo hezká složitost O(n). Mám fakt rád tyhle akademické "počítání" složitosti. A režije na vytváření toho stromu, kopírování v paměti a podobně je vosk? Teorie je to hezká, ale skutek utek. Složitost O(n) to má leda tak na papíře.

[moira]

Slozitost na vytvoreni stromu je take O(n), je to v tom clanku :)

[Hynek (Pichi) Vychodil]

Vážně? Jseš si tím tak jistý, že by jsi za to dal ruku do ohně? Tak se na to mrkněme pod drobnohledem. Takže v ukkonen95() se nám n krát volá funkce upDate() a canonize(). A copak to tu máme uvnitř funkce upDate()? Na dvou místech se nám tu volá funkce test_and_split() to jednou doknce uvnitř cyklu! Takže jen funkce test_and_split() je volána více než O(n). No pak tu máme další volání funkce canonize() uvnitř funkce upDate() a zase uvnitř cyklu! Funkce canonize() je opět volána vícě než O(n)! No a aby to nebylo málo, tak funkce canonize() opět obsahuje cyklus z čehož vyplývá, že ta část uvnitř cyklu se provede ještě víckrát než samotná funkce canonize(), která sama o sobě není volána O(n), ale víckrát. Takže prdlačky švagrová. Ten algoritmus není O(n) ani kdybych zavřel obě oči a praštil se palicí do hlavy. Dokonce bych ho typoval tak na O(n^3) ná základě tohoto rozboru. Když to srovnám s kódem co jsem poslal, který má nejhorší odhad (n+2)*n/8 tedy O(n^2) a to počítám opravdu ten nejhorší případ. Nesmíš taky věřit všemu co se kde píše. Ono takhle akademicky to vypadá dobře, ale když jdeš po tom algoritmu do důsledku tak se nám tam n krát zavolá cosi co má v sobě cyklus uvnitř něhož se nám zase zavolá ? krát cosik a to cosik má v sobě cyklus, která může být zavolán m krát, přičemž hodnota m je nějaká konstanta*n. Tedy přinejmenším O(n^2), ale taky možná O(n^3) protože neznám ?. Abych pravdu řek, nechce se mi po tom pátrat, ale vzhledem k tomu, že je to cosi se stromy, tak tomu dejme O(n^2*log2n) ať nežeru. O(n) fakt ani omylem.

[Michal Kubeček]

Až na to, že všechny vaše úvahy jsou jen horní odhady…

[Hynek (Pichi) Vychodil]

Vážně? Ve funkci ukkonen95() jsou funkce upDate() a canonize() volány vždy n krát. Uvnitř funkce upDate() je funkce test_and_split() vždy volána nejméně jednou, ale může být i více krát. Stejně tak funkce canonize() je vždy n krát volána přímo z ukkonen95() a může být volána i z upDate() a to i více než jednou. Takže tu máme dvě funkce, které mohou být volány n*a, kde a není nikdy menší než 1, ale a s velkou pravděpodobností závisí na složitosti stromu tedy asi na O(log2n). No a v samotné funkci canonize() máme cyklus, který závisí na délce subřetězce, tedy na n. Takže tvrdit o něčem takovém, že to má složitost O(n), je prostě lež jako věž. To neukecáte, ani kdyby jste se na hlavu postavil. Jen proto, že se v javě až tak nevyznám, jsem možná přehlédl ještě nějaké to kopírování v paměti zase se složitostí O(n), které nám z toho všeho pěkně udělají nejméně O(n^2) jako když vyšije. Mužete to milionkrát okecat, ale O(n) to prostě není.

[Michal Kubeček]

Nehodlám nic ukecávat, to, co jste předvedl, nemá s důkazem dolního odhadu časové složitosti nic společného a silácké výrazy typu "prdlačky švagrová" nebo "ani kdybych zavřel obě oči a praštil se palicí do hlavy" tomu nijak nepomohou. Nevidím sice na první pohled, že to je lineární, ale stejně tak bych si nedovolil na základě tak chatrných úvah, jako jsou ty vaše, rezolutně prohlášovat, že to lineární není.

[Hynek (Pichi) Vychodil]

Nehodlám nic ukecávat, to, co jste předvedl, nemá s důkazem dolního odhadu časové složitosti nic společného a ...

Ahá, takže ono jde o dolní odhad složitosti, tak to ten můj algoritmus má taky dolní odhad O(n). Pro řetězec neobsahující žádnou dvojici za sebou jdoucích stejných znaků se provede právě n-1 porovnání. Aha, takže proč to dělají tak složitě? Ten můj algoritmus je mnohem jednodužší a má stejný dolní odhad složitosti

[Michal Kubeček]

Achich ouvej. Chcete-li vyvrátit tvrzení, že univerzální horní odhad složitosti je O(n), potřebujete najít nějakou posloupnost vstupů, pro niž je dolní odhad složitosti není O(n), tj. označíme-li jejich složitosti t_n, posloupnost t_n/n není omezená. Takže chcete-li vyvrátit horní odhad (a právě o to se celou dobu snažíte), potřebujete udělat dolní odhad. Dolní odhad jste sice udělal, ale dokázal jste pouze cn, což nic nevyvrací, všechny další výroky, že je to určitě n log n a pravděpodobně n^2, jsou jen mlha, ne důkaz.

[Michal Kubeček]

Ještě doplnění: pozorný čtenář si toho jistě všimne sám, ale pro ty méně pozorné zdůrazním, že jediné, co jste svou v tomto příspěvku úvahou skutečně dokázal, je skutečnost, že časová složitost je alespoň O(n), což není nijak v rozporu s příspěvkem, do kterého jste se tak vehementně obul…

[podlesh]

Pro ty méně i více pozorné bych ještě dodal, že přehození pojmů "horní" a "dolní" odhad celou tuto diskusi naprosto dorazilo. Doporučuji začít znovu.

[podlesh]

Aha, už vidím podrobnější vysvětlení, teď to dává smysl

[Martin Beránek]

Mám fakt rád tyhle akademické "počítání" složitosti.

V tom pripade vam doporucuji toto PDF.

[Hynek (Pichi) Vychodil]

To je všechno hezké, ale ten algoritmus nemá složitost O(n), ale větší.