Diskuze: Porovnání rychlosti bubblesortu
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.


Zobrazeno 6 zpráv z 6.
K personalizaci obsahu a reklam, poskytování funkcí sociálních médií a analýze naší návštěvnosti využíváme soubory cookie. Informace o tom, jak náš web používáte, sdílíme se svými partnery pro sociální média, inzerci a analýzy. Partneři tyto údaje mohou zkombinovat s dalšími informacemi, které jste jim poskytli nebo které získali v důsledku toho, že používáte jejich služby.
Používáme nezbytné cookies pro fungování webu a s tvým souhlasem také analytické a marketingové cookies.
Zajišťují základní funkce, bezpečnost a služby, které sis vyžádal. Nelze je vypnout.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| ITnetwork | ITnetwork | Provoz webu, relace, přihlášení a uložení nastavení cookies. | PHPSESSID, auth_token, sid, itn_consent_impression, __Host-itn_consent | Relace až 1 rok |
| Google Tag Manager | Správa značek a načítání měřicích nástrojů webu. | Žádné | Neukládá se | |
| Google Fonts | Načítání typografie webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google Hosted Libraries | Načítání potřebných knihoven a stylů webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google reCAPTCHA | Ochrana formulářů a webu před zneužitím. | _GRECAPTCHA, rc::a, rc::b, rc::c, rc::f | Relace až 180 dní | |
| YouTube | Přehrávání vloženého video obsahu. | localStorage, IndexedDB; cookies after playback interaction | Relace až trvalé úložiště | |
| Vimeo | Vimeo | Přehrávání vloženého video obsahu. | __cf_bm, _cfuvid, vuid, localStorage, IndexedDB | Relace až 2 roky |
| Facebook Login | Meta | Přihlášení pomocí účtu třetí strany. | Úložiště řízené poskytovatelem | Relace až 1 rok |
| GoPay | GoPay | Zpracování uživatelem vyžádané platby. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
Pomáhají nám porozumět používání webu a zlepšovat ho.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Analytics 4 | Měření návštěvnosti a používání webu. | _ga, _ga_* | Až 2 roky | |
| Microsoft Clarity | Microsoft | Měření návštěvnosti a používání webu. | _clck, _clsk, _cltk | Relace až 1 rok |
Slouží k měření kampaní, personalizaci reklamy a marketingové komunikaci.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Ads | Měření kampaní, reklama a remarketing. | _gcl_au, _gcl_ls | Relace až 90 dní | |
| Meta Pixel | Meta | Měření kampaní, reklama a remarketing. | _fbp, _fbc, localStorage | Až 90 dní |
| Sklik | Seznam.cz | Měření kampaní, reklama a remarketing. | retargeting, sid, szn:* | Relace až trvalé úložiště |
| LinkedIn Insight | Měření kampaní, reklama a remarketing. | bcookie, li_gc, lidc, __cf_bm | Relace až 1 rok | |
| Ecomail | Ecomail.cz | Měření kampaní, reklama a remarketing. | ecmid, Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
| Atribuce kampaní ITnetwork | ITnetwork | Přiřazení návštěvy a objednávky ke kampani. | campaign_clid[*], user_session_context | Až 1 rok |
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.


Pokud ti to nejde lineárně zrychlit, tak časová složitost není
lineární. Ono by to i dávalo smysl, protože BS ji má kvadratickou v
nejhorším případě (čísla jdou pozpátku a vše se musí prohodit) a
lineární v tom nejlepším (je to již setříděné). Ty máš něco mezi,
takže to nebude tak, že to 4x zlepšíš a on se 4x zrychlí
Nejlepší budeš mít, když si
vypíšeš pod sebe jednotlivé kroky (obsahy pole po projetí vnějšího
cyklu) a uvidíš, kolik jich to musí udělat oproti úplně náhodnému
poli.
Úvod do časové složitosti zde na síti jsi předpokládám četl - https://www.itnetwork.cz/…st-stabilita
Díky, toho, že obtížnost neroste lineárně jsem si vědom.
Nicméně uvažoval jsem takto, že z většiny seřazené pole na tom bude daleko lépe než "náhodné" (přes Random).
Výsledky, které jsem teď porovnal mezi náhodným (první čísla patří k normálnímu, 2. k vylepšenému)
Pocet kroku je 199990000
RunTime 00:00:02.26
Pocet kroku je 199860205
RunTime 00:00:02.32
a 3/4 uspořádaným
Pocet kroku je 199990000
RunTime 00:00:01.07
Pocet kroku je 199702339
RunTime 00:00:01.07
Oba s 20000 prvky, čísla od 1 do 20000.
Očekával bych, že metoda vylepsenyBubbleSort bude v 2. případě znatelně lepší v porovnání s 1. Ve skutečnosti je tomu spíše naopak.
Je to podle tebe v pořádku?
Může to být správně. Nejsem matematik, ale kvadratická složitost je sviňa. Když si představíš, že seřazené pole o 10 prvcích to udělá za 10 porovnání (lineární složitost), ale náhodné za 100 prohození. Tak u 20000 prvků je ten rozdíl |20000 - 400000000|. Počítám krok jinak než ty, ale naskáče to tam slušně. To vylepšení to prostě o tolik nespraví a vzhledem k tomu, že jsou tam nějaké instrukce navíc (další proměnná a práce s ní), může to být ve finále i pomalejší. Můžeš to ještě zkusit s menším počtem prvků.
Ty ten algoritmus nezlepšuješ na úrovni složitosti, tak je stále
stejná, takže pro dostatečně velká n to bude stejné, což +/-
je.
Asi to tak vypadá. Moje původní představa o projití toho seřazeného pole byla, že by se z toho "vytahaly" ty čísla navíc (většinou jsou řádově větší než ty okolo) na konec a zbyly by ty víceméně seřazené.
Trochu jsem si s tím ještě hrál (intervaly vložení nahodných čísel a velikost pole), a zdá se mi, že u menších polí, jsou ty rozdíly skutečně nejvýraznější.
Zkus si napsat insert sort s tim, ze neporovnavas pole od 0, 1, 2, 3... ale odprostredka, pulku, pulku...
Bubble sort funguje takto:
ooooooo1
oooooo1
ooooo1
oooo1
ooo1
oo1
o1
1
Coz je velike mnozstvi porovnavacich operaci (suma(o)+suma(1)).
suma = 8+7+6+5+4+3+2+1 = 15 + 11 + 10 = 36
Insert to middle v nejhorsim pripade
1.
o1.
xo1.
xoo1.
xxoo1.
xxoxo1.
xxxoxo1.
xxxoxoo1
Opet, suma o a 1. x je hodnota, ktera se neporovnava.
suma = 1 + 2 + 2 + 3 +3 + 3 + 3 + 4 = 10 + 5 + 6 = 21
Pocty porovnani podle delky pole by sly napsat i takto:
x
00
01
000
001
010
011
0000
0001
0010
0011
0100
...
Zpet k tve otazce...
Tvuj algoritmus se snazi napodobovat quick sort, ale ne tak uplne. Ktery
samozrejme v nejhorsim pripade ma stejne skore jako bubble sort. Nejhorsi pripad
pro nej nastava u serazeni pole opacne, 9,8,7,6,5,4,3,2,1.
V podstate dela totez co bubble sort. Jedina zmena je v tom, ze muze skoncit o
neco drive.
Ja jsem si delal takove slozitejsi testy, kdy jsem sledoval cas, za jak
dlouho seradi algoritmus pole. Pole, bud vygenerujes 1000 nahodnych cisel nebo
od 0 do 999 a pak to zamichas.
krok1: zkopiruje 0-10 z pole, zapni cas, serad pomoci alg1, zapis cas[0] a
suma_cas[0].
krok2: zkopiruje 0-10 z pole, zapni cas, serad pomoci alg2, zapis cas[1] a
suma_cas[1].
if (suma_cas[0]<x) potom zastav krok1 pro pole 0-100
if (suma_cas[0]<x) potom zastav krok2 pro pole 0-100
...
Cim dele algoritmus vydrzi, tim je rychlejsi.
https://mlich.zam.slu.cz/…sorting3.htm
[+ effective], start effective
Neprijemne je, ze moderni cpu a prohlizece maji optimalizace, takze si pamatuji
vysledky z prechozich kroku, pokud byla pouzita stejna data a stejne algoritmy.
Takze, treba ve Firefox naskakuji ty casy divne 
Ten druhy test, tam mam asi zrovna nastavene nejake neodladene veci, ktere se
zacykluji
Ten zac pocita pocet
operaci.
Ano, pocet operaci porovnani ma vliv na rychlost. Ale take dalsi operace. Jako
napriklad presun prvku. Ten rozdil vidis u klasickeho insert sortu a
upraveneho.
A jeste mma jeden zajimavy test. Serazeni 4 cisel.
https://mlich.zam.slu.cz/…-sort-x2.htm
Cim mensi cislo Avg, tim lepe.
Zajimavy je prvni sloupec. to je naticni alg. prohlizece. Zkus Explorer, Edge,
Operu, Chrome, Firefox (co mas). Kazdy pouziva neco jineho.
Zobrazeno 6 zpráv z 6.