• Úvod
• Excel návod
• Excel šablony
• Nástěnka
• Mobility
• Tipy na výlet
• Galerie
• Fórum

Příspěvky uživatele

Téma vlákna zní: Generátor náhodných unikátních čísel. V zadání se dodává "v určitém rozsahu čísel". Ani slovo o řešení pomocí vzorců.
Tady je to, co bylo požadováno, tedy generátor.

1. Od Excelu 2007 neplatí omezení na 7 vnoření KDYŽ.
2. Pokud větvení vyplývá z jedné vstupní hodnoty, která má pokračování rozvětvit podle intervalu, do kterého hodnota spadá, pak lze s výhodou použít nsledující konstrukci:
=ZVOLIT(POZVYHLEDAT(<co>;{<seznam mezí>});
<volba-1>;<volba-2>;<volba-3>[;…])co je hodnota, která rozhoduje o větvení
seznam mezí je seznam hodnot, oddělených středníky a uzavřený do složených závorek jako array
volba-i může být číslo, odkaz na buňku, definovaný název, vzorec nebo znakový řetězec.
Maximální počet možností pro tuto konstrukci je 256.
Příklad konkrétního vzorce:
=ZVOLIT(POZVYHLEDAT(A1;{0;5;10;15});$B$1;$B$2;$B$3;$B$4)

Začalo to zaokrouhlováním na čtvrthodiny. Skončilo to válkou o rychlost jedné obyčejné UDF. Mezitím ležel můj názor, že koncept Excelu s mnoha zaokrouhlovacími funkcemi lze nahradit jednou funkcí s parametry. Napsal jsem něco ve VBA, co mohli napsat pánové z Microsoftu v céčku a co by pokrylo větší prostor, než jejich neuspořádané stádečko nestejnorodých funkcí. Nesnažil jsem se napsat rychlou, ale zato univerzální zaokrouhlovací funkci. Nic víc jsem v úmyslu neměl. A taky jsem napsal, že to pro sebe pokládám za laboratorní příklad s ukázkou možností, protože já odjakživa zaokrouhluji a i dále zaokrouhlovat budu po svém.
Doufám, že mne za mou drzost s napsáním RoundX nakonec nikdo neupálí. Pro mne kauza zaokrouhlování skončila. Bylo by nejspíš rozumné, aby byla vlákna s 30 a více příspěvky přímo zakázána.

to Lubo:
možná budu za brouka Pytlíka, ale v zaslaném sešitě je Test-Lubo s výsledky 0,3/0,5 pro Ceiling a 0,8/0,8 pro RoundX a také Test-Vovka s výsledky 0,934/1,117 pro Ceiling/RoundX.
Žádné další testy jsem v sešitě nenašel. U výsledků testů pro 200 tisíc řádků je proti mým číslům lehce zavádějící přechod od mých sekund k milisekundám v těchto testech. Cca 3 sekundy na přepočet 200 tisíc řádků pro RoundX mi nepřipadne zarážející. Zarážející mi naopak připadne změřený čas pro přepočet 200 tisíc řádků Ceiling za 0,015/0,037 sec. To vypadá spíš jako chyba algoritmu, než jako reálný výsledek. Tak rychlý zase podle mých zkušeností Excel není (při vší úctě k zabudovaným funkcím Excelu).
Poslední dvojice čísel z mého testu pro 200 tisíc řádků (0,578/0,703 sec pro Ceiling/RoundX podle mého testu) to podle mne dokládá. Jde o čistý čas výpočtu, oproštěný od veškeré myslitelné režie. Lze si jen obtížně představit, že změřený čistý čas 0,578 sec výpočtu Ceiling bez režie může být vyšší než uvedený čas 0,038 sec pro přepočet stejného počtu vzorců v buňkách (což sebou jistou režii nesporně nese).
Buď jde o chybu vyhodnocení, nebo Excel funkci Ceiling přepočítává, jen když je to nutné. To by bylo chytré, ale pak by to nebyl čas přepočtu, ale čas kontroly, že počítat není nutné. O ničem podobném v souvislosti s metodou Calculate nevím. Nechám se poučit...

Velmi vítám konec této velmi neblahé polemiky. Toto fórum má sloužit otázkám a odpovědím na praktické problémy, nikoliv žabomyší válce o počet andělů na špičce jehly. Tady mluví slepý k hluchému...
Howgh!

Chvíli mi opravdu trvalo, než jsem pochopil, co ta procedura dělá. Teprve nakonec mi došlo: v té proceduře strávíte 99,9% času tím nejpomaleji možným plněním buněk a jen její nepatrný zbytek bude počítat pomocí funkce, případně vzorce, zaokrouhlené hodnoty.
Toto není test na rychlost funkce, toto je test na pomalost práce s buňkami.

Přesto odpovím: přes hodnotové pole cca třicetkrát rychleji. Z toho JPG se nedalo vyčíst víc než výsledky, v žádném případě konkrétní způsob použití. Čísla ale říkají, že použití nebylo nejvhodnější. Zkušenost mne naučila, abych přestal říkat "líp to nejde", protože poctivější je říct "líp to neumím".

to elCHa:
>>>(RoundX) jsem integroval do souboru, který obsahuje desetitisíce výpočtů a události change a je prošpikován kódem. Tam už prohrála a to jsem musel počet cyklů snížit na 100 (oba spodní případy - u toho prvního jsem zapomněl změnit text).
To s naprostou jistotou není způsobeno tou funkcí samotnou, ale jejím nevhodným použitím.
>>>Pokud toto někdo má, jedná se o pokročilého uživatele, který na to přijde, zjistí příčinu a opraví si. (Týká se změny chování funkce bez změny jejího jména)
To je chyba úvahy. Stovky mých sešitů běhají někdy už deset let po světě mezi jejich (často anonymními) uživateli a stále dobře slouží. Jak by tito uživatelé, postižení novým chováním funkcí, měli hledat, co se to stalo, že jim jejich starý dobrý sešit začal běhat za roh? Jednorázové psaní sešitů "sám pro sebe" je málo produktivní využití vývojářské práce.
>>>UDF je pomalejší, protože si ji musím napsat a odladit.
Pro jednorázové použití - naprostý souhlas. Pro úlohy s dlouhou životností - argument nanic. Čím víc uživatelů má úlohu používat a čím déle to mají činit, tím víc se vyplácí do úlohy vložit vývojářskou práci. Čas, ušetřený v provozu, by měl vždycky zaplatit čas vývojáře. Když mohu ušetřit stovky hodin v provozu, neměl bych se ohánět hodinovou vývojářskou pracností. Je to stejné jako s fixními a provozními náklady.
>>>UDF je nehorázně otravná a pomalá, když potřebuji ladit nějaký projekt (krokovat) a je v listu obsažena několikrát (mohou to být stovky - vlastní zkušenost).
Podobnou zkušenost jsem měl před lety taky. Pak jsem se zamyslel a našel jednoduchý způsob, jak ladit jeden samotný vzoreček: stačí na tu chvíli vypnout Volatile.

Vypadá to, že jste se trefil. Je to zvláštní, ale nevzpomínám si, že bych někdy událost Terminate použil. Budu se muset podívat do chytrých knih, co všechno UserForm.Terminate dělá. Člověk se má pořád co učit. Možnost zeptat se je k nezaplacení. Jednou vím já, jindy někdo jiný. Už Werich zpíval "ten umí to a ten zas tohle, a všichni dohromady uděláme moc". Dík!

Při experimentování s formulářem o proměnné velikosti jsem narazil na zvláštnost, pro kterou neznám vysvětlení ani programátorsky čisté řešení.
Pokud sešit zavolám k jinému otevřenému sešitu, zobrazí se v tom dosud aktivním sešitě můj zavolaný nemodální formulář. To funguje dobře, to chci.
Zavřením nemodálního formuláře křížkem vpravo nahoře se zavře i celý sešit s formulářem. I to je dobře, tak jsem se to snažil napsat.
Potíž nastala, když jsem se po zavření pokusil opět svůj sešit otevřít (aniž bych mezitím přerušil práci s Excelem). Z důvodů, které jsem neodhalil, vznikne při tom chyba 429. Po přeskočení chyby se sešit otevře, ale bez nového otevření formuláře. Během hledání příčiny vadného chování jsem s překvapením zjistil, že opakovaný pokus o otevření už projde bez závady. A tak nyní mám v událostní proceduře Workbook_Open
následující nehezkou konstrukci
On Error Resume Next
PoloPruh.Show 0
If Err <> 0 Then
PoloPruh.Show 0
End If
Prostě, když se to nepovede napoprvé, tak to zkusím podruhé - a uspěji. Nic ošklivějšího jsem snad nikdy nenapsal. Protože to ale funguje a já lepší řešení nemám, tak to tam je.
Pokud někdo odhalí příčinu a najde čistší řešení, udělá mi tím radost. Inkriminovaný sešit je v příloze.

Odklon od českých názvů k angličtině (a následné zapomenutí těch českých názvů) by vážně znehodnotilo spoustu české literatury jak v knižní, tak v elektronické podobě, která s českými názvy samozřejmě pracuje. Proto je celá diskuse o opuštění českých názvů trochu akademická.
Důkazem, že nejsme sami, kdo si z lokálních názvů funkcí utahuje, je půvabný návrh polského názvu pro IF:
CHCELIPANTOTOBOTAMTO.
Mohu uvést českou (a zcela autentickou) podobu podmíněného příkazu v jazyce MAT-5 (jazyk vymyslel Ing.Formandl kolem roku 1965):
JELI A3:B20 SKOKNA 120:150:90
(vyhodnoť rozdíl A3 a B20; pro <0 skoč na řádek 120, pro =0 na řádek 150 a pro >0 skoč na řádek 90).
Než jsem potkal Excel, věřil jsem, že už takovou ptákovinu nikdy nepotkám. Mýlil jsem se ...

Pro svůj archiv jsem přehled upravil a doplnil o některé poznatky z proběhlé diskuse. Zejména jsem si ale do přehledu vložil ten výkonový test, o kterém jsem se již zmínil. Kdo chce, může si novou verzí přepsat tu původní.
Mně osobně se tahle diskuse opravdu líbila a přinesla mi skutečný užitek. Na některých otázkách jsme se vzácně shodli. O jiných si myslím, že stojí zato je zrekapitulovat:
Lubo: mně by také zajímalo, proč přidávají další fce, když stačí opravit ty staré. Pokud se bojí zpětné kompatibility, tak se bojí špatně.
Obávám se, že to není tak jednoduché. Pokud by oprava změnila chování funkce a v některém starém sešitu by tu chybou někdo vědomě využíval, začal by se ten starý sešit chovat vadně. Změna chování funkce si podle mne přímo vynucuje nové jméno funkce.
marjankaj: No pri zaokrúhľovaní záporných čísel pri MROUND možno použiť napríklad =MROUND(A1;SIGN(A1)*5)
Tohle by v žádném případě nemělo zaniknout! Je to pěkné a úplné řešení toho problému; jenom by se nemělo zapomenout na to, že k tomu je také nutno zakázat záporný interval pro druhý parametr. Jen se sám sebe ptám, jak tahle zjevná chyba funkce mohla uniknout Microsoftu...
elCHa: Určitě bych ale nepoužil pomalou UDF a raději se obrátil na rychlejší ROUND.
Každé tvrzení má mít své opodstatnění. Proto jsem provedl svůj výkonový test, o kterém píšu shora.
elCHa: Navíc - pokud jsem to pochopil CEILING, FLOOR jsou přeložené, ale ty s tečkou už ne...
Jak to tak vypadá, jména funkcí listu jsou přeložena vždycky a všechna. Jen u některých je pro "překlad" použito jejich originální znění. Jinými slovy: moje brojení proti českým názvům má snadné technické řešení. To spočívá v prosté výměně jednoho souboru v knihovně Excelu za jiný. V tom okamžiku začnou vzorce na listu pracovat s originálními jmény funkcí (ale s českou interpunkcí !!). Kdybych hodně hledal, tak jména těch souborů k záměně někde vyštrachám.

Nějak se k vám rady nehrnou a ani vy nepospícháte s dodáním podkladů. Když jsem si nechal proběhnout možnosti, jaké má v daném případě "téměř úplný začátečník", vychází mi snad jediná rada. Zkuste začít souhrnem. V nápovědě se podívejte, jak se s ním pracuje a jaké poskytuje možnosti. Když to shledáte účelné, přihrajte nová data pod ta předchozí a všechno setřiďte sloupcem, který nese jednoznačnou identifikaci výrobku. Když z toho teď uděláte souhrn po výrobcích, dostanete první nástin jakéhosi přehledu o nich. Dál už asi budete muset použít vlastní hlavu, pokud se ovšem nenajde někdo, kdo vaši práci udělá za vás...

Ještě že existují staré dobré manuály. U Walkenbacha jsem našel "podmíněné formátování čísel" a s trochou násilí jsem sesmolil formát, který u mne pracuje správně. Ten formát vypadá hrozně:

[<1000]0,00;[>999999]#\.###\.000,00;#\.##0,00

Když ale funguje, tak se dá použít !

to marjankaj: žádná mezera nevadí; zbytečné # se vynechají, natvrdo vložené \. se zobrazí ...

dodatečné upřesnění: místo >999999 je správnější >=1000000

marjankaj radí dobře, až na to, že kratší číslo, např. 1234, se zobrazí jako .1.234,00. Pokud ta tečka vlevo nevadí, je to řešení.

Uživatelské menu

Nejste přihlášen(a)

• přihlásit
• registrace

\n

Menu

On-line nástroje

Formulář Faktura

Aktivní diskuse