Diskuze: Porovnání každého záznamu s každým
Zobrazeno 4 zpráv z 4.
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 |
Při použití standardních řadících algoritmů není potřeba nikam zapisovat jednotlivé "velikosti" - prostě porovnáváš jeden prvek s jiným.
[Termín k vyhledání Total Order]
Předpokládám teď, že to tvoje porovnávání je tranzitivní, antisymetrické a reflexivní. To jsou totiž přesně 3 požadavky na komparátor použitý v řadícím algoritmu, pokud chci docílit totálního seřazení.
O co teda jde lidsky řečeno:
Tranzitivita: Pokud platí, že A ® B a také B ® C => A ® C.
Pokud je Adam menší než Bob a Cyril je větší než Bob, pak je Cyril
větší než Adam.
Antisymetrie: A ® B a B ® A pak určitě A = B nebo jinak řečeno A ® B
=> NOT B ® A pro všechna A různá od B.
Pokud je Adam alespoň tak vysoký jako Bob a Bob je alespoň tak vysoký jako
Adam, pak jsou stejně velcí. Jinak řečeno, pokud nejsou stejně velcí, pak
nemůžou být oba alespoň stejně velcí jako ten druhý.
Reflexivity: A ® A pro všechna A.
Adam je alespoň tak velký jako Adam.
Všimni si, že na relační symbol ® dobře sedí neostrá nerovnost. Menší rovno nebo věští rovno.
Pokud tohle platí ve tvém systému, tak bys to měl normálně seřadit quicksortem nebo mergesortem správně.
Zdroje:
https://en.m.wikipedia.org/…/Total_order
https://en.m.wikipedia.org/…ng_algorithm
https://www.itnetwork.cz/…itmy-razeni/
Pokud mas male pole, tak je vyhodny insert sort, ale misto od zacatku
porovnavas vzdy stred pole, stred zbyle casti, atd.
Pokud mas delsi, tak je lepsi quick sort.
A co ti brani pouzit nativni algoritmus tveho programovaciho jazyka? Ze
potrebujes vytvaret vlastni reseni?
https://www.geeksforgeeks.org/…n-list-sort/
https://mlich.zam.slu.cz/…sorting3.htm
Jeste muzes zkusit takovy muj pokus. Ale neni to moc dodelane a prehledne 
2. Vyberes Efectivity test, kliknes Start efectivity.
1. U Algorirmus kliknes (fast), to by melo zaskrtnout 15 algoritmu. Pocet prvku je vybrany 1000. Kliknes Start.
Nevyhoda je, ze tam muzou byt chyby a neco je nedodelane a je tam chaos v kodu, obcas.
Nej algoritmy jsou zname:
Pro 10.000 prvku:
A zajimave mozna bude pro tebe porovnani 4 cisel, pokud chces stahnout pocet
cmp a budes si pamatovat vysledky prechozich operaci. Viz Taskkill, ti to krasne
vedecky rozepsal 
https://mlich.zam.slu.cz/…-sort-x2.htm
Pokud bys mel moznost multi-threading, tak lze udelat algoritmus, ktery otevre 3
vlakna. A jedno z nich po 3 krocich serazeni ukonci. Cili, idealni algoritmus.
cmp = n - 1, pocet porovnani je roven (poctu prvku - 1). U 10.000 by to bylo
9.999 a ne 120.000
Ale mel bys
rozjetych 10.000 vlaken, nebo, tak nejak (mozna 10.000x10.1000). V podstate neco
jako bubble sort.
Zobrazeno 4 zpráv z 4.
