Příspěvky uživatele

@ eLCHa
Netušil jsem, že lze vytvořit pojmenovaný maticový vzorec. Z Vašeho příkladu to neplyne. Ale vyzkouším!

Zajímavé řešení přes Names. Jak ale ta buňka pozná, že jde o maticový vzorec?
Napadá mne jiná cesta přes Names. Udělal jsem si rozbor vzorce od elninoslov, který ukázal, že vzorec obsahuje čtyři shodné dlouhé sekvence. Uložením té sekvence do Names a její volání do konečného vzorce by ho zkrátilo nejmíň na polovinu. Svůj automatický rozbor obsahu původního vzorce přikládám v podobě obrázku.

Nikoho tady snad neohromím informací, že maticový vzorec se ve VBA vkládá do vlastnosti Range.FormulaArray v notaci R1C1. Vybaven touto znalostí jsem tak učinil. Při vkládání vzorce pro věčný kalendář jsem si přitom tvrdě natloukl nos. Teprve když jsem si pořádně přečetl Help, zjistil jsem, že maximální délka řetězce pro FormulaArray je 255 znaků. A ten vzorec jich ale měl 261 !!! Důvod pro toto omezení nechápu, protože maticový vzorec může být prakticky i podstatně delší.
Vůbec nejdelší maticový vzorec, který jsem objevil, pochází z dílny elninoslov. Jeho úkolem je extrahovat číslo z řetězce s alfanumerikou. Vzorec má v české lokalizaci 439 znaků a skutečně řádně funguje. Ale do vlastnosti FormulaArray ho pro jeho délku pomocí VBA vložit nelze.
Vyjadřuji hluboký obdiv autorovi, že takový funkční vzorec dokázal sestavit. Kladu si ale otázku, jestli je takové řešení účelné. Vsadím se, že bych dokázal napsat UDF ve VBA, která by umělo všechno, co ten megavzorec, a které by se skládalo z menšího počtu znaků, než ten vzorec. A hlavně - bylo by nepoměrně srozumitelnější...

@ elCHa
kdysi jste se na mne rozčílil, že jsem nedodržel přesné znění Vašeho nicku. Teď se Vám povedla žertovná úprava mého jména (opravu jen překlep?) Karle, domníval jsem se, že se budeme respektovat. K čemu je Vám posměch?
Excel objevuji 20 let a stále mám co objevovat. O tom formátu vím cca 18 let a jsem rád, že si ještě dokážu vzpomenout. Vám, který jste snědl moudro z hovna, se samozřejmě rovnat nemohu a ani nechci.
Navíc toto vlákno bylo určeno těm v Excelu, kteří danou informaci neznají a mohla by se jim hodit. Vám jsem ji opravdu neadresoval!

@marjankaj
Naprosto dávám za pravdu, že je to pro země s německou tradicí zápisu čísla hodně matoucí formát. Daleko lépe je na tom zápis stejného formátu ve VBA, např.:

Selection.NumberFormat = "#,##0.000,,"

Petře, už zase spolu diskutujeme. Pokud si odpustíme invektivy, pak mi to nevadí. Dovol, abych silně nesouhlasil s Tvým výrokem o mém filozofickém blábolu, což invektiva nesporně je.
Teď ke Tvé definici efektivity. Paměťová náročnost je přísně technický parametr, který uživatel naprosto nevnímá, pokud nenarazí na hranice svého hardwaru.
S časovou náročností jako kriteriem efektivity naopak plně souhlasím, ale ta musí být vztažena k celé době životnosti daného řešení (včetně předpokládané intenzity využití za dobu užívání). Jsou úlohy "na teď", kdy je nejefektivnější rychlé řešení, třeba na úkor doby zpracování dat. A jsou úlohy typu "furt a na roky", kdy naopak rychlost zpracování dat je dominantní i za cenu delší doby projekce. To nemusí být o lenosti řešitele, to je o posouzení, k čemu dané řešení slouží.
Posuzovat časovou efektivitu odděleně pro řešitele a pro provoz naopak pokládám za zásadní chybu úvahy.

Petře, a podíval jsi se do té přílohy, kterou jsem přidal? Kdyby jo, třebas bys mi porozuměl!
Volba formátu "Číslo" je jistě méně komplikovaná, stejně jako volba "Text" pro číselné literály. Mne ale napadlo zobrazení s řádovým posunem, vhodné zejména pro zpracování statistických dat. Kolik takových, kdo tohle ví a používá, znáš Ty?

Dostal jsem dotaz z jiného fóra. Tazatelka získává externí data v podobě csv souboru. Jde o tak velká čísla, že se v buňkách obrazují v matematickém (semilogaritmickém) tvaru, např. 8,456E+15. Hledala způsob rozumnějšího zobrazení takového čísla.
V Česku (i na Slovensku) se ten problém zpravidla řeší snížením řádu čísla jeho vydělením jedničkou s patřičným počtem nul. Velmi málo známé u nás je, že se to dá bez dělení přímo řešit pomocí formátu buňky.
Napsal jsem pro tazatelku instruktáž na toto téma. Třebas se hodí i některým z vás.

Pravděpodobně máte nastavenou vlastnost Application.TransitionKeys na hodnotu True. Když ji nastavíte na False, bude se zobrazovat pouze apostrof, a to jen tehdy, pokud ho sám před text umístíte. Tento apostrof se v buňce nezobrazuje a dovoluje vkládat texty s aritmetickými znaménky na prvním místě (jako když má buňka nastavený formát "@" - text). Ten znak se v buňce umisťuje do vlastnosti PrefixCharacter, která je ovšem "read-only", takže ho ve Vašem případě nelze mazat. Při vypnuté vlastnosti TransitionKeys se vložený apostrof objeví v řádku vzorců a lze ho smazat. Pokud se nemýlím, v Možnosti / Upřesnit je nastavení TransitionKeys předposledni z možných nastavení.

Lubo, dík za vzorec! Pokud máte víc takových lahůdek, pošlete mi je prosím na moji adresu. To se týká i ostatních, kteří by měli k dispozici nějaké vykutálené příklady vzorců. U těch maticových prosím o uvedení oblasti na listu, pro kterou vzorec platí. Poslouží mi k rozsáhlejším testům mého formátovacího algoritmu. Předem dík!

Efektivitu lze posuzovat z více pohledů. Pokud jde o dobu, potřebnou k vyřešení problému, je pro mne nepoměrně rychlejší napsat proceduru ve VBA, než vymýšlet složitý maticový vzorec. Věřím, že to mají jiní obráceně, ale já píšu VBA přibližně stejnou rychlostí jako dopis (asi se umím přepnout do módu VBA).
S rychlostí výpočtu jsou asi maticové vzorce rychlejší než VBA, i když jsem se dočetl, že moc rychlé zase nejsou. Zato přinášejí komplikace, pokud mají obsluhovat měnící se počet buněk.
S pochopitelností výpočtu to zase bude odlišné podle toho, komu se lépe čte vzorec a komu VBA. Mně určitě VBA.
Skončím konstatováním, že megavzorce (a zvlášť ty maticové) jsou nášlapné miny pro dědice po odešlých řešitelích. Vím o mnoha případech, kdy "nerozluštitelný" vzorec zabránil aktualizaci chování celého sešitu.
Tyhle problémy se netýkají nikoho z těch, kdo tady v tomto vláknu diskutují. Zato mají zásadní význam pro málo pokročilé vývojáře.

Vlákno bych rád uzavřel díkem místní elitě, která se diskuze zúčastnila. Překvapivě jednoduché řešení od elCHa dokládám v příloze pro porovnání s řešením od Johna Walkenbacha.
V žádném případě nezpochybňuji slova diskutujících ani nezkouším exhibovat. Jen se snažím poradit těm, kteří toho vědí ještě míň než já.

pro Luba: za dvacet let hrátek s Excelem jsem v žádné své aplikaci nepoužil ani jeden maticový vzorec. Původem jsem programátor, a kde obyčejné vzorce nestačily, ve 100% případů stačil VBA (někdy jako UDF). Jediný případ, kde ve vzorcích listu používám pole, je SOUČIN.SKALÁRNÍ. A ten mám rád zejména proto, že ho není nutné vkládat do maticového vzorce.
Teď si s maticovými vzorci hraju jen proto, abych je dokázal správně formátovat. Zjišťuji přitom, že mám ještě pár věcí, které musím dotáhnout. Můj obdiv k Walkenbachovu kalendáři vzbudilo právě to, že se mi konečně maticový vzorec odměnil hezkým výsledkem. Řešení od elCHa bez maticového vzorce je ale rovnocenné, takže můj potlesk jeho maticovému řešení lehce utichá.

pro Luba: vzorec není z internetu, ale z tištěné knihy od Walkenbacha (resp. z přiloženého CD). Když to bylo tak jednoduché, proč jste ten vzorec neopravil?

pro elCHa: nabídnuté řešení funguje, zejména proto, že v použitém vzorci nechybí u funkce DENTYDNE druhý argument pro určení týdne Po-Ne. To bylo podstatou chyby "neděle prvního", kterou objevil mepexg.

pro oba: nesnažím se ohromovat znalce. Hledám metody, které usnadňují život těm, kteří toho umějí mnohem méně, než vy dva.

pro všechny: v příloze je sešit s opraveným kalendářem

Už to mám! Nebudu ale kazit radost z hledání ostatním. Pokud ale do zítřka nikdo nezveřejní opravený kalendář, pak tu svoji opravu předvedu.

Příspěvky uživatele

Uživatelské menu

Menu

Formulář Faktura

Formulář Faktura IV

Helios iNuvio

On-line nástroje