Opoměl jsem. Ve výpočtech je dobré vypnout přepočet tabulek.
Pokud ladím složitější výpočet, používám citlivostní analýzu, tabulka dat.
V případě jedné proměnné lze tak rychle zjistit a zaznamenat výsledky při různých vstupech, včetně mezivýsledků.
Pokud potřebuji otestovat více než 2 vstupy, je třeba trochu přemýšlet. Nejprve, jestli je to opravdu nutné.
Obvykle mi stačí citlivost výsledku ke změnám jednotlivých vstupů, druhá proměnná mi určuje, do která buňka se má měnit. Zjistím snadno citlivost výpočtu na různé vstupy. Fakticky tak v jednom kroku provedu více výpočtů s jednou proměnnou.
Jinak, pokud to opravdu nutné je, lze třeba tabulky zřetězit.
Fakticky jsem se k tomuto dostal když jsem zkoušel, jestli lze použít výstup z jedné tabulky dat jako vstup do druhé.
Pro jistotu, pro někoho možná některé detaily citlivostní analýzy nemusí být samozřejmé:
Vzorec, která tabulka dat vyhodnocuje, je prostý odkaz na výsledek výpočtu.
Měněné buňky jsou na listu s tabulkou a vstupy výpočtu na tyto buňky odkazují.
Pokud řeším více vstupů (citlivost, často užitečné) je nutno trochu upravit výpočet:
"Normální" vstupní data jsou jinde a v původní vstupní buňce je vzorec typu:
když(2.měněná buňka má moje číslo; vezmi 1. měněnou buňku; vezmi "normální" vstup)
Zkusil jsem to trochu jinak.
V souboru jsou v obou listech na 1. řádku číslo a vzorce =ZAOKR.NAHORU(A1;0,01) na listu CEILING
a =roundx(A1;0,1;1) na listu RoundX
Na řádku 200000 je zarážka, která usnadní zkopírování 1. řádku dolů.
Měřil jsem dobu přepočtu a úplného přepočtu obou listů s vyplněnými 200 tis. řádky. Přepočet se opakoval 5x a výsledkem je průměrný čas.
Výsledky:
List CEILING
Přepočet: 14,7 msec
Úplný přepočet: 36,9 msec
List RoundX
Přepočet: 3101,1 msec
Úplný přepočet: 3098,1 msec
Pro srovnání výsledek testu Vovky pro 200000 opakování:
Ceiling : 578 msec
RoundX : 703 msec
Můj závěr:
1. Metoda WorksheetFunction má o hodně vyšší režii, než volání funkce z listu.
2. Volání UDF z listu je o dost pomalejší než volání té samé funkce z listu.
K tomu cyklu.
Obvykle používám tabulku dat
@eLCHa
Částečně se chyba řeší, u funkcí CEILING a FLOOR ve 2010 přidali varianty CEILING.PRECISE a FLOOR.PRECISE, u kterých nezáleží na znaménku 2. parametru.
A ve 2013 doplnili funkce CEILING.MATH a FLOOR.MATH, které se blíží k tomu, co poslal Vovka (lze nastavit způsob zaokrouhlení záporných čísel).
Nechápu, proč opravují jen funkce CEILING a FLOOR.
Propagovaný "dolovací" sloupec nefunguje v případě porovnání listu.
Varianta s odkazy z pomocného listu zdánlivě vypadá lépe, ale pokud vytvořím propojení na celý list, tak prázné buňky najednou nejsou prázdné.
Takže to "Funguje to, jako když vystřelí z praku." platí jen v některých případech (bez prázdných buněk).
"Ručně" mazat odkazy na prázdné buňky není zrovna něco k doporučení.
Zbývá tedy jen kopie hodnot (vložit jinak, hodnoty, vynechat prázdné)
Pokud to má běhat automaticky, tak zřejmě makrem načíst porovnávané hodnoty a porovnat. A možná najít mechanismus na snažší hledání ve větším souboru.
Pokud porovnávám sešity, tak pro moji potřebu a používám pro definici odkazu některou formu jmen.
@Vovka
Pozor na definici jmen s relativním odkazem. Taky jsem líný a používám to, ale občas se odkaz posune o nějaké políčko.
Dovolil jsem si tabulku trochu doplnit a pozměnit některé komentáře.
Možná, že několik peprných slov ještě přibude.
Nedoplnil jsem další zaokrouhlovací funkce, např. WORKDAY, WORKDAY.INTN, HODNOTA.NA.TEXT, možná jsem něco dalšího vynechal.
@marjanka
Možná tomu nebudeš věřit, ale
Počítače existovaly už před rokem 1981.
Programy pro tabulkové výpočty existovaly dlouho před rokem 1985 (např. VisiCalc, Lotus123). Excel nebyl ani první ani nejlepší.
DOS nabízela IBM pro řadu 360 kolem roku 1965.
Jen netestované nápady.
Zkusil jste deklarovat bez uvedení cesty?
Předpokládal bych, že pokud bude knihovna na vhodném místě (např. ve stejném adresáři jako soubor), tak by mohla být nalezena.
Pokud to selže, je tu vždy možnost použít win api:
LoadLibrary
FreeLibrary
GetProcAddress
CallWindowProc
A dopsat rozhraní.
Ok. Chybu ve vybarvování jsem opravil. Zpravidla hledám rozdíly, aby to hledalo shodu, bylo nutné změnit vzorec v podmíněném formátu (buňka A1).
místo
=pf1_2<>A1
má být
=pf1_2=A1
Není to samozřejmě dokonalé, jde o obcházení omezení v Excelu. Pro rychlé porovnání dvou otevřených sešitů mi to obvykle stačí.
Do zavřeného souboru takto definovaný podmíněný formát nevidí. Nevylučuji, že s jinou funkcí by to šlo.
Jinak Excel4makro funkce lze používat ve jménech. Excel toto pak vyhodnotí jako makro v sešitu a sešit se musí uložit jako xlsm.
Jde o docházku a pesonalisti nejsou filosofové. Správné je to, co je podle nastavených pravidel.
Mohl jsem napsat třeba:
=KDYŽ(M27>=96,01;NEPRAVDA; MAX(CELÁ.ČÁST((M27-0,01)/12)+1;0))
@Vovka
Ovšem z komentářů v dotazu jsem odhadl, že vstupní hodnoty jsou nejspíš celočíselné. Původní vzorec je v takovém případě jednodušší.
Obecně ale problémem těchto vzorců je jejich chování u hraničních hodnot intervalů, proto jsem na to upozornil.
Ostatní podmíněné dotazy beru jako přehlédnutí.
@elninoslov
Otevřete nejprve sešit pf2, potom pf1.
(V opačném pořadí otevírání je nutné provést nějakou změnu v oblasti A1:A7 sešitu pf1)
p.s. Berte to spíš jako zajímavost, případně pro jednorázové použití.
@Vovka
Co to vráti, když M27 = 12.
Podmínku, že každého musím poslat někam jinam jsem nějak přehlédl.
Lze to řešit doplňující podmínkou, že každý cyklista může být vybrán nejvýše jednou.
Ze zadání ovšem nevyplývá jasné kriterium optimálního řešení.
Lze např. nastavit parametry na dojezd mezi prvním a posledním v libovolném městě: Cíl G23
Nebo minimalizovat rozdíly mezi dojezdy v jednotlivých městech: Cíl F18 (Míra L1, lze snadno modifikovat na L2)
Oblíbený formulář Faktura byl vylepšen a rozšířen.

Více se dočtete zde.
Používáte podnikový systém Helios iNuvio? Potřebujete pomoci se správou nebo vyvinout SQL proceduru? Více informací naleznete na stránce Helios iNuvio.