Já se přiznám, že s Excelem moc nekamarádím a nedovedu to správně porovnat, ale s těmi LOOKUP(y) se to má pro získání přehledu následovně :
HLOOKUP - znamená Horizontal - tedy jako řádky
VLOOKUP - znamená Vertical - tedy jako sloupce
LOOKUP - znamená něco jako navštívit, nebo podívat se ale přeložit se to asi dá také jako "vyhledat". Při tom nerozhoduje zda se prohledává řádek, nebo sloupec, takže LOOKUP umí to co ty dvě specializované funkce dohromady.
Je tedy k zamyšlení, proč je tam jednou univerzální řešení, a k tomu ještě řešení specializovaná. Důvod to má, ale z nápovědy se porovnání dá vyčíst jen velmi obtížně - i když to tam nepřímo je. Univerzílní LOOKUP umí hledat jen v seřezených úsecích. Konkrétně sestupně, nebo vzestupně. Takže spíš náhodou dá někdy správný výsledek. Je to značná slabina této funkce. Specializované funkce také tuto variantu (setřídění) upřednostňují, ale dá se zvolit navíc prohledávání nesetříděného úseku. A právě tohle univerzální řešení neumí. Zdá se to divné - proč? Zase tyto vlastnosti mají důvod - ten je v algoritmu.
Algoritmus funguje takto : Funkce prohledává úsek z jednoho konce na druhý. Když LOOKUP narazí na větší hodnotu, nežli je hledaná skončí bez výsledku, když hodnotu najde dá výsledek. Je to vlastně o rychlosti. Specializované funkce projdou celý úsek. Samozřejmě když narazí na hledanou hodnotu skončí. V režimu nesetříděného úseku jsou ale značně pomalejší.
Vyhledávací algoritmy jsou podobné s algoritmy pro třídění. Některé vyhledávají i nejbližší hodnotu k hledané a tady jsou podobné například ShellSortu, nebo i BubleSortu. Algoritmus porovnává hodnoty pole s hodnotou zadanou. Takže realizační script udržuje v paměti jak hledanou hodnotu, tak hodnotu nejblíže nižší. Když narazí na hodnotu, která je blíže k hledané - dá ji do paměti místo původní a pokračuje - tady je podobnost se "sorty". Když tedy narazí na vyšší hodnotu, porovná absolutní hodnotu rozdílu mezi nižší a vyšší. Z toho vrátí buď hodnotu nejblíže nižší, nebo nejblíže vyšší. Nyní už pochopíme jak propastný rozdíl je mezi vyhledávání v setříděném a nesetříděném úseku.
Když je úsek setříděný, může funkce skončit hned jak narazí na hodnotu vyšší. Když není setříděný musí projet celé pole a při tom musí udržovat v paměti jak hodnotu nejblíže menší, tak hodnotu nejblíže větší.
Ve finále ještě musím dodat, že se jedná o binární vyhledávání a to u OOo je ztíženo tím, že to jde pomocí Javy, která není žádný rychlík. Samozřejmě se používají také jiné programy - zejména z takových důvodů - ale jde vždy o zprostředkování - nepřímo. Nejnověji LO v Pythonu, čímž se zřejmě dostává na úroveň rychlosti Excelu (ale s tím si nejsem moc jistý).
Takže Excel si možná může dovolit 1 funkci na vše, ale OOo se muselo přizpůsobit podmínkám plynoucích z výpočtové náročnosti algoritmů. Vím například podle Bugg hlášení, že Calc LO uměl spadnout když dostal "štos" k setřídění - snad je to už v pořádku. Také je pravdou, že se používají různé druhy algoritmů a to jak ke třídění, tak k vyhledávání. Viděl jsem nějaké porovnání "sortů" a ne vždy všechny druhy dopadly jednoznačně. Jako nejlepší byl vyhodnocen QuickSort z pohledu "průměru", ale například zůstal daleko za ShakerSortem, nebo i snad BubleSortem pokud se jednalo o třídění "malých" objemů. Ale značně překonal všechny konkurenty v běhu na dlouhou trať.
V praxi se nám to projeví například tak, že vzorec má uvedeno, že můžeme zadat "až" 30 hodnot (parametrů). Většinou ale umí "bez problému" i mnohem více. Jenže do těch 30-ti používá jiný algoritmus, nežli za touto hranicí, a výsledek je zřejmě "bez záruky".
Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ