Diskuzní fórum Elektro Bastlírny

Tak kde mám chybu? Mám pridať zaokrúhľovanie na niečo čo je jasne celé číslo? Excel nevie počítať a basta. Taký príklad že 1234,56-1234 spočíta z hlavy aj žiak základnej školy.

Keď v orámovanom políčku vypočítanú 6 prepíšem ručne na 6, tak v žltom políčku je to zrazu správne.

PotPalo píše:Tak kde mám chybu?

V hodnocení.

Na skladě mají 0,56 lopat, což bude asi jedna lopata bez násady.

Kde?! Keď to vypočítané 0,56 prepíšem na 0,56 ručne, tak zrazu zvyšok funguje ako má.

Tak hele, lopato, niečo sa môže počítať aj v tonách. Tam je 0,56 tony bežné.
A či máš dostať 0,55 alebo 0,56 miliónu je tiež sakra rozdiel.

To nepočíta excel, ale počítač. Otvoril som to v Libre Office pod Linuxom a ukazuje to rovnako "zle". Chyba, či skôr nepochopenie (nespráva implementácia) je až v poslednej funkcii CHOOSE(). V predchádzajúcich riadkoch stačí znížiť počet zobrazovaných miest.
Kždopádne, pri numerických výpočtoch, na rozdiel od algebry, je vždy potrebné dbať na správny postup. Pri správnom postupe sa chyby zaokruhľovania eliminujú, pri nesprávnom znásobuju.

https://support.microsoft.com/sk-sk/off ... 653b98f5bc

Ak je hodnota argumentu index_číslo zlomok, skráti sa pred použitím na najbližšie nižšie celé číslo.

Teda funkcia CHOOSE() aplikuje na neceločíselný index pred použitím funkciu INT(), nie ROUND().

Ale keď vidím vypočítané celé číslo 6, tak CHOOSE by malo pracovať správne, teda so 6.

Pokiaľ musím 6 zaokrúhľovať aby bolo 6, tak excel nevie počítať, a to mu už nikto neodpára. A je mi jedno kde tá chyba vzniká. Pokiaľ v O.S. má si to excel počítať vlastnou rutinou.

6 môže byť aj znak, jún, alebo sobota. Ak chceš presný výsledok, musíš mať nastavený správny formát bunky.

@PotPalo: Až ti projede silniční váhou 20x sklápěčka např. s pískem, tak těch 0,56 tuny bude jen nepřesnost při vážení a ty tady chceš s 15 desetinnými místy dělat tyjátr, jak na skladě bude chybět 0,0123456789876543210 tuny.

Pokiaľ máš piesok, tak na to sere pes. Pokiaľ ale vážiš zlato, to už je iná trieda. A štát má kopec zlata.

Sranda ako sa vždy všetci chopia obhajovania nejakej nájdenej chyby. Prehlásime chybu za vlastnosť a je to v poriadku.

Ja som upozornil iba na jednu chybu. Nieje vylúčené, že ich tam je hromada ďalších. Stačí si pamätať jedno: softvér nieje neomylný, a presný už vôbec nie.

Kolikrát týdně na/vy-skladňují těch 0,56 tun zlata? Že na to potom musí vzít kalkulačku.

PotPalo píše:Tak kde mám chybu?

Neuvědomuješ si, že Excel interně nepočítá v desítkové soustavě, ale ve dvojkové. Ne-celá čísla v desítkové soustavě pak často mají ve dvojkové soustavě nekonečný rozvoj za “desetinnou” čárkou. To je případ i tvého 0,56 což si Excel interně uloží jako 0,100011110101110000101000111101011100001001111111111000001111111 a to je těch tvých 0,55999999999994500.
Prostě je třeba vždycky počítat s tím, že neceločíselné výsledky jsou vždy přibližné. S přesností, která zpravidla postačuje.

Pokud nechceš desetinná čísla, použij datový typ integer, pak žádné zlomky mít nebudeš. Desetinné čísla Excel ukládá jako float a tam nějaká nepřesnost na nízkých řádech bude většinou vždy. Ale dělají to tak všechny tabulkové procesory, neznám zádný jež by ukládal data s pevnou desetinnou čárkou. Tam ale zas mohou vznikat řádově větší chyby při dělení než ve floatu, takže si stejně nevybereš. Pokud se ti někde objevují zlomky které nechceš, není to dáno softem, ale tím že ho neumíš používat.

Většinou jsou ty chyby zanedbatelné. Typ float má dost bitů na mantisu (double má 53 single 24 když počítám i nepsanou jedničku), takže rozlišení je přesně dané právě na 53 bitů (52 je uloženo, padesátý třetí je vždy jedna tak se nepíše, 11 je na exponent a jeden na znaménko). Takže mantisa je nejmíň 2⁵³=9 007 199 254 740 992 (a nejvejš 2⁵⁴-1 tj. cca 18e15 prostě dvojnásobek) čemuž odpovídá chyba, která je vždy relativní k tomu číslu, které je jako základ. Poskytuje teda rozlišení na zhruba 15-16 desítkových řádů.
0.55999999999994500-0.56=-0.00000000000005500 tedy chyba je až na čtrnáctém místě v porovnání s výsledkem (a o 4 víc v porovnání se vstupními čísly). Hlavní příčinou je zobrazení - ještě 10 míst za očekávaným výsledkem by se zaokrouhlilo ke správné hodnotě (0.560 000 000 000) až na jedenáctém místě by to selhalo (0.559 999 999 999 9). Nezapomeňte ale, že původní číslo bylo 1234,56, chyba vznikla už při jeho převodu do dvojkové soustavy.
Vězte, že tu samou chybu udělá Matlab, asi bych ho měl u Humusoftu reklamovat. Zase je vidět, že když se zobrazení přepne na long tedy na vyšší rozlišení (defaultně je short). A kterýkoliv jiný sw by udělal totéž, pokud by použil k výpočtu typ double a donutil by se k zobrazení tolika moc desetinných míst (vím, že existují i další typy, s plovoucí i pevnou řádovou čárkou s větším rozlišením, ale double je prostě standard). Jinak tohle bývá problém, pokud máte nulu jako podmínku ukončení programu. Já takové šílené programy nedělám, teda hlavně nemusím (jen pbčas narazím na něco co vypadá šíleně, dokud si nevšimnu, že na svislé ose je třeba 10^-250 teda nula). Ale říkal člověk, se kterým jsme spolupracovali, že takto mu běžel program asi 2 dny a když mu to už bylo divné, tak se podíval, co dělá a právě jak tam měl jako podmínku nulu, tak se k ní furt nemohl dostat, a už tam byly taky nějaké takové pro praxi bezvýznamné drobné.
Tohle je prostě všeobecná vlastnost počítání na počítači, to nezasahuje jen excel, ale veškeré programy. Většinou to neni problém. Ale pokud potřebujete počítat na hodně platných číslic, už je potřeba se nad tím zamýšlet. Asi jako když se normalizovaly čísla pro osmibity, to se řešilo, jestli bude stačit rozlišení cca 1.4 úhlového stupně (360 stupňů (2pi) byl plný rozsah odpovídající 256) a to samé s proudem, napětím, kmitočtem, dělaly se tehdy i nějaké simulace, kam jsem tohle kvantování musel explicitně zahrnovat (simulace jinak počítala s double, na fixed point by se musel dokupovat toolbox, tak se to muselo řešit jinak).
No ale existují číselné typy stavěné na něco takového, třeba financial nebo jak se jmenuje, to jsou 64 bitová čísla, která ale mají desetinou čárku posunutou o 4 místa. Takže jsou to normální fixed point, ale dají se s nima počítat i halíře (až na setiny halíře). Možná jak jsou teď populární ty bitkojny, tak na ně mají taky něco, vzhledem k tomu, že ten se dělí na 6 desetinných míst a prý se může v budoucnu dělit i na víc.

Tak ono by mi vôbec nevadilo, keby to presne počítalo na tie dve desatinné miesta ktoré tam mám.

Tak si to na ně zaokrouhli....