Příspěvky uživatele


< návrat zpět

Strana:  1 ... « předchozí  28 29 30 31 32 33 34 35 36   další » ... 37

Dnes jsem Gorgymu poslal řešení, se kterým jsem ho zjevně potěšil. Bližší informace o použití Řešitele od Luba bohužel nedorazily, takže sem dávám alespoň to svoje řešení, které sice nenachází se zárukou skutečné optimum, ale přesto velmi slušné suboptimální řešení.

Omlouvám se za moc drsný posudek, asi nemám nejlepší den. Na Listu2 jsou data ve sloupcích L:O v pořádku. Rozhoduje to, že ty sloupce mají uvedený dobrý formát.
Myslím, že chcete použít vzorce. Pak do druhého řádku sloupců L:O napište vzorce:
=ČÁST(List1!L2;1;10)
=ČÁST(List1!L2;11;10)
=ČÁST(List1!L2;21;10)
=ČÁST(List1!L2;31;10)
Takto vyplněný řádek zkopírujte do potřebného počtu dalších řádků. Není nutné řešit ani mezery místo dat, ani existenci datumu v poslední položce. Vzorce si s tím poradí samy. Důležité je, že texty ve sloupci L na Listu1 tvrdě dodržují rozdělení po 10 znacích.

Všechno jde, když to má nějaká pravidla. Váš příklad není z hlediska svých pravidel moc šikovně vymyšlený. Řetězec 40 znaků, kde jsou bez separátorů vloženy čtyři termíny s časovým oddělovačem tečka, je klasická ukázka, jak se to dělat nemá. Ale rozluštit to jde. Jen to bude zbytečně složité.
Převod termínů v podobě data na List2, ale jen když na Listu2 žádné datumy nejsou, je už problematický. Ve vašem příkladu jsou buňky ve sloupcích L:O obsazeny, ovšem nikoliv datumy, ale špatně vyhodnocenými znakovými řetězci. Jde o obsazené buňky, nebo to jsou logicky prázdné buňky?

Myslím, že každém dotazu by měl předcházet pokus o využití zabudované nápovědy. Během jedné minuty jsem pod heslem sdílení v nápovědě našel vše, co potřebujete vědět. Nevidím důvod, proč bych měl tu nápovědu tlumočit (je v češtině). Tohle je plýtvání časem lidí, kteří by mohli dělat něco užitečnějšího 9 !

To je typický případ pro využití události Worksheet_Change. V události je nutno pečlivě ošetřit, kterých buněk se událost týká, jinak ta událost může mít "nedozírné následky". A taky by bylo dobré vymyslet, čím viditelnost skrytých sloupců obnovit. Samo se to neudělá!

Nejspíš došlo ke kolizi při duplicitní změně ve stejných buňkách v době mezi dvěma uloženími. Zkuste odstranit tu kolizi. Excel na to má nástroj, který jsem nikdy nemusel použít, protože se úzkostlivě vyhýbám módu sdílení s přístupem více uživatelů do stejných dat. Proto ani neumím poradit, jak taková náprava má probíhat.

Kdysi jsem objevil příčinu záhadného chování u některých sloučených buněk. Roky mi to sloužilo výhradně k tomu, že jsem věděl, jak to chování vzniká a jak ho napravit. Teď poprvé vidím, že by se to mohlo hodit i jako záměrné a chtěné chování.
Klasicky při sloučení obsazených buněk dojde k zachování obsahu pouze první buňky ve sloučené oblasti. Pokud ale na slučovanou oblast vložím formát jiné sloučené oblasti (Domů/Schránka/Kopírovat formát), použije se ten formát bez promazání buněk, které sloučení v tomto případě pouze překryje.
Pokud tedy ve sloupci Přípravek natvrdo uvedu názvy do všech řádků a následně bloky se shodným obsahem překryjí importovaným formátem sloučené oblasti, pak se vlk nažere a koza zůstane celá. Když bude vidět celá sloučená oblast, uvidím jen její první řádek. Pokud se při filtrování něco ze sloučené oblasti skryje, začnou být vidět jinak skryté texty.
Doteď jsem si myslel, že jde o chybu Excelu, dobrou maximálně tak pro rafinované skrytí obsahu buněk. V daném případě to má skutečný logický význam.

V příloze je zobecnění úlohy pro nestejné počty cyklistů v cílových městech. To zadání je užitečné v tom, že použití druhé fáze neposkytuje úplné řešení a že musí nastoupit fáze s vracením dříve vyškrtnutých polí do hry. Pro tuto fázi mne nenapadl žádný jednoduchý postup. Řešení, které v sešitě uvádím, stojí pouze na empirických úvahách.

Metoda branch and bound sama o sobě je velmi prostá. Jiná otázka je, v jakém vědeckém trojobalu ji dnes na internetu prezentují. O její průhlednosti svědčí to, že jsem si celou metodu bez velkých potíží vybavil, a to jsem lhal se třiceti roky. Z výzkumáku jsem odešel v roce 1975, takže optimalizace už nedělám ne třicet, ale čtyřicet let...
Na své sekernické řešení úlohy jsem se šel ještě jednou podívat a s překvapením jsem zjistil, že na první fázi škrtání extrémů lze plynule navázat. Když v tabulce zůstanou bílé hodnoty, znamená to, že každou z nich mohu bez narušení podmínek úlohy smazat; jak v řádku, tak ve sloupci zatím je pro její smazání prostor. Teprve kdyby smazáním nepodbarvené hodnoty došlo k nepřípustnému podbarvení jiných hodnot, pak by nastala skutečná chyba a musel bych se vrátit krok zpátky. Konkrétně v našem příkladu mi po první fázi zbyly nepodbarvené hodnoty C4, D6 a C9. Jejich postupné mazání nezpůsobilo žádnou poruchu, takže tím nakonec vzniklo zdravé a úplné řešení případu.
Netvrdím, že by to takhle dobře nutně dopadlo pokaždé, ale ta druhá fáze stojí za povšimnutí.
Vzpomínka na moji výzkumnickou éru ve mně probudila zájem o tu úlohu. Nevylučuji, že pro ni vytvořím optimalizační algoritmus s využitím zmíněné metody branch and bound. To na počest naší tehdejší skupině matematických metod a Jirkovi Kubátovi, na kterého jsem si dnes se slzou v oku vzpomněl...
Ale to až jestli na mne přijde ta správná "sedmá chuť".

Existuje deset rozumných cest, jak takovou kontrolu provést. S propojovacím odkazem v podmíněném formátu jste použil tu jedenáctou 8.

Pokud nemáte v ruce nic chytřejšího, než to moje postupné škrtání, pak máte naprostou pravdu, že "můj" automat skončí tím, že už nesmí smazat ani minimum, ani maximum.
Když ten zbytek nebude moc rozsáhlý, šlo by v něm dál škrtat metodou pokus / omyl. S dobře vymyšlenou rekurzí byste nejspíš zpravidla našel řešení hodně blízké optimu. Pokud je cílem najít hodnotu minimálního rozdílu, tak tu dostanete už v rámci první fáze.
Problém ovšem spočívá v tom, jestli zbytek po "mém" škrtání obsahuje alespoň jedno přípustné řešení. Mohlo by se stát, že zbytek nepůjde plně zredukovat, protože některá ze škrtnutých mezních hodnot musí v úloze zůstat, aby úloha zůstala řešitelná do konce.
Kdysi dávno jsem se optimalizacemi zabýval profesionálně. Už jsem všechno zapomněl, protože od těch časů uběhlo třicet let. Přesto si dovolím dát vám tip: zkuste se zeptat strýčka Google na heslo "branch and bound", případně na variace toho pojmu. Jde o stařičkou, ale velice obecnou metodu hledání optimálního řešení. Metoda dává záruku nalezení optima, pokud dostane na hledání dostatečný čas.

Spadnul mi kámen ze srdce 5! Notaci R1C1 pokládám za geniální vynález např. kvůli tomu, že všechny rozkopírované vzorce mají ve své oblasti totožné znění R1C1. Jejich jazyk mi je ale cizí a těžko stravitelný (čtu ho pomalu a nerad).
Jediný skutečný problém s notací při psaní vzorců podle mne vzniká, pokud vzorec plním kódem VBA. Tam musím zapomenout na použití .FormulaLocal, abych nezpůsobil malér při budoucí práci s jinojazyčným Excelem. Ale vložení vzorce v notaci A1 do .Formula vždy dokáže nahradit vložení odpovídajícího vzorce v notaci R1C1 do .FormulaR1C1.
To říká mých patnáct let manželství s Excelem.

Mám upřímný (a zcela neosobní) dotaz: je opravdu nutné řešit nastavení těch vzorců v notaci R1C1? Podle mých zkušeností (s výjimkou několika málo situací, v nichž help přímo uvádí povinnost použít specifickou notaci) lze vzorec psát, "jak mi zobák narostl" a teprve na samém konci (v případě nezbytnosti) použít převod na R1C1. Domníval jsem se, že nedávná diskuse o automatických převodech notace vzorců do věci vnesla jasno. Je možné, že jsem něco podstatného přehlédl ?!?

Vracím se k poznámce elCHa o možnosti využít vlastnosti .Tag aktivních prvků pro jednodušší práci při psaní formulářů s proměnlivou velikostí. To je dobrý nápad, který jsem s úspěchem zabudoval do svého dema. Navíc jsem události propracovanějšího druhého formuláře doplnil o řádky kódu pro změny velikosti na výšku. Jen jsem je "zaremoval", protože je ten formulář nevyužívá.
Při použití jako vzoru pro jinou úlohu se to může hodit. Upravenou verzi posílám v příloze.

Politik by pravil, že jde o hluboké nedorozumění. Vůbec jsem nechtěl být útočný. Vycházím z toho, že naše příspěvky do fóra čtou i jiní než my dva. Pokládám za rozumné, aby v příspěvcích pokud možno nebyly zbytečné chyby, které snižují jejich využitelnost. Nefunkčnost sešitu pokládám za zbytečnou chybu. To je vše, co jsem chtěl říct.
Za jakýkoliv osobní nádech mých příspěvků se dozadu i dopředu omlouvám. Jediným jejich smyslem jsou kvalitní služby tohoto fóra. Za tu chvilku, co tady jsem, si u mne toto fórum získalo důvěru a úctu.
A co se týká reakcí - co jiného než reakce může doložit, že si příspěvek někdo přečetl a že dokonce měl chuť odpovědět. Reakce jsou podstatou diskuze. Uznávám, že by neměly dráždit.


Strana:  1 ... « předchozí  28 29 30 31 32 33 34 35 36   další » ... 37

Uživatelské menu

Nejste přihlášen(a)
avatar\n

Menu

Formulář Faktura

Formulář Faktura IV

Oblíbený formulář Faktura byl vylepšen a rozšířen.
Více se dočtete zde.

Helios iNuvio

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.

On-line nástroje