Umí Excel počítat?

Zpráva

AmarokCZ · #16 Příspěvek od **AmarokCZ** » 02 říj 2010, 18:17

Věděl by někdo jak ošetřit problém aniž bych v možnostech nastavoval "přesnost dle zobrazení"??
Sešit s náznakem problému je tady.

#17 Příspěvek od **Hill** » 02 říj 2010, 18:31

A proč ti to nastavení vadí?
Použij pomocný sloupec po výpočet argumentu a zaokrouhlování třeba na 6 míst. On totiž ARC... neumí ze vzorce počítat, pokud je úhel těsně kolem 0 a atgumentem funkce je vzorec.
Já bych řekl, že tě to zase nijak časově nezatíží ve srovnání s tím, kolik ti zabere třeba jen sestavování vzorců, neřkuli krmení tabulky daty.

AmarokCZ · #18 Příspěvek od **AmarokCZ** » 02 říj 2010, 18:36

Vadí, protože přesnost je pak na *****

#19 Příspěvek od **Hill** » 02 říj 2010, 18:54

S pomocnou buňkou A5, z níž si bere konečný vzorec argument pro ARCCOS, to máš tady na obrázku.
Nastavil jsem zaokrouhlení na 12 platných míst, ale můžeš i víc.

AmarokCZ · #20 Příspěvek od **AmarokCZ** » 02 říj 2010, 20:58

Diky Hille, sice to není ideálně jednoduché řešení, ale funguje to. Mě by tohle ani nenapadlo, protože pomocné buňky jsem si neoblíbil a pokud to není nutné z formálního důvodu (např. pokud je pomocná hodnota i výstupem), tak vše dám do jednoho dlouhého vzorce.
Času to moc nezabere, ale každý čas navíc se hodí na něco jiného

Je taky docela zajímavý, že tu chybu to dělá jen při určitém čísle v A1 ... mno prostě mrkvo$oft

#21 Příspěvek od **tomasjedno** » 02 říj 2010, 22:26

Problém není ve vložené funkci, ale v tom, že Excel počítá na víc míst než ukazuje a výsledek výpočtu který se jeví jako 0,3 může být v Excelí interpretaci skutečnosti třeba 0,3000000000000004 nebo 0,2999999999999995 a člověk nemá šanci to zjistit. Proto mu zřejmě vyšel argument arccos větší než 1 a to se mu nelíbí. Řešením je vložit tam na argument arccos zaokrouhlovací funkci.

Excel dělá i horší věci. Zkuste si pomocí funkce MOD zkontrolovat, jestli je vaše rodné číslo beze zbytku dělitelné 11 (což by, pro narozené po 1.1.1954, mělo být). Můj Excel 2002 ani 2003 SP2 to neumí. Největší celé číslo, pro které to umí, je 1476395007.

Edit: nebo lépe, funkce MOD(Číslo, Dělitel) funguje jen pro
1) je-li dělitel kladný a (-Dělitel*2^27 +1)<Číslo<(Dělitel*2^27)
2) je-li dělitel záporný a (Dělitel*2^27)<Číslo<(-Dělitel*2^27 -1)
To znamená, že počítá celočíselný podíl jen na 27 bitů, zatímco normálně počítá na 50+ bitů (tuším že 54, ale zobrazuje zaokrouhlení na 50).
P.S. 2^27 = 134 217 728

AmarokCZ · #22 Příspěvek od **AmarokCZ** » 02 říj 2010, 23:00

tomasjedno: to co píšeš je pravda, ale to, že počítá na konečný počet míst a pak díky tomu místo 1 je 1.00...x je problém EXCELu a mělo by to být nějak ošetřené, protože to znemožňuje normální práci (ale to nikomu asi ještě nikdy nevadilo).

#23 Příspěvek od **Hill** » 02 říj 2010, 23:19

Už jsem na podobné potíže taky někdy narazil, ale ošetřuji si je tím, že si udělám pomocné buňky, ať se v tom později, až zapomenu, co jsem to vlastně tvořil, snadněji zorientuju bez složitého dekódování dlouhých vzorců. Aspoň mám jasno, co který sloupec vůbec dělá, a ty pomocné můžu skrýt.

Obávám se, že Excel používá algoritmus ukládání čísel daný operačním systémem, takže ta chyba nevzniká v Excelu.

Už u osmibitů způsobovalo ukládání čísel s plovoucí desetinnou čárkou problémy (například u Spectra se vyměňovaly EPROMky s Basicem kvůli takovým chybám, jako PRINT -1 způsobil, že na obrazovce se objevilo číslo 65535, protože všechna čísla se ukládala jako mantissa a za ní exponent). Při převodu na "lidskou" interpretaci zkrátka k této chybě došlo.
Kdyby tehdy bylo možné definovat předem přesnost čísla, problému by si nejspíš dlouho nikdo nevšiml.

#24 Příspěvek od **mtajovsky** » 03 říj 2010, 23:23

Tvar uložených čísel v pohyblivé řádové čárce si řídí každý program sám, a kompilátor si je ukládá v závislosti na tom, jakou matematickou knihovnu používá. Přesné výpočty v dekadické soustavě s pohyblivou řádovou čárkou jsou v principu možné při uložení čísel v BCD a k tomu existují různé knihovny jako třeba:

* Borland's C++ BCD class
* Zortech's C++ BCD class
* Zortech's C++ money class

Samozřejmě jsou výpočty v BCD daleko pomalejší, a proto, pokud nejde třeba o peníze nebo není jiný důvod , se to běžně nepoužívá.

Andrea · #25 Příspěvek od **Andrea** » 04 říj 2010, 09:00

mtajovsky píše: * Zortech's C++ money class

A opravdu je to pro výpočty v pohyblivé řádové čárce?

#26 Příspěvek od **mtajovsky** » 04 říj 2010, 14:43

Jak se vezme, v podstatě ano, jenom to není v BCD, ale rozděleno na long dollars a int cents. No a mezi nimi je ta čárka. V každém případě bude:

$4.1 - $.1 - $4 = $0

přesně.

Andrea · #27 Příspěvek od **Andrea** » 04 říj 2010, 15:39

Takže je ta čárka pevná, nikoliv pohyblivá.

#28 Příspěvek od **mtajovsky** » 04 říj 2010, 16:30

Chjo... rozcvička na večer, čekají mě 2 dcery a manželka.

PotPalo · #29 Příspěvek od **PotPalo** » 09 říj 2010, 00:00

Takže malá skúška v Exceli:

do C10 napíš:
=CHOOSE(C9+1;"nula";"jeden";"dva";"tri";"štyri";"pät";"šesť";"sedem";"osem";"deväť")
Teraz do C9 skús písať čísla od 0 do 9. Funguje to, že? Tak teraz do C9 napíš:
=INT((C8*10-INT(C8*10))*10)
Teraz skús písať do C8 čísla s dvoma desatinnými miestami. Malo by to brať v úvahu druhé desatinné miesto a vypísať ho slovom. Lenže pri niektorých číslach to ukazuje zle! Napríklad pri 1234,56. Skús prísť na to, kde je chyba...

Alebo: do A1 napíš 1234,56 a do A2 napíš 1234. Do A3 napíš =A1-A2. Vidíš výsledok 0,56. Tak skús klikať na "Pridať desatinné miesto" (aspoň 15 krát), to sa budeš diviť. Samozrejme si nastav širší stĺpec, aby sa tam tie desatiny zmestili.

#30 Příspěvek od **tomasjedno** » 09 říj 2010, 01:19

Co tě na tom překvapuje?
To už by tě mohlo překvapit i to, že SIN(PI()) = 1,22514845490862E-16

Pokud potřebuješ, aby argument funkce bylo přesně to, co vidíš, vždycky si to musíš zaokrouhlit - jinak tam riskuješ chybu v 16.-17. číslici mantisy.