?Sčítanie? v CALCu - CHYBA LO/OO

Roman Toman · 26. 12. 2012 11:56:20

Narazil som na zaujímavý problém. Neviem aký algoritmus používa CALC pri sčitovaní čísel, ale vychádzajú mi zaujímavé výsledky viz. priložený obrázok. Postupnosť v stĺpci "A" bola vytvorená pomocou vzorcov z východzej hodnoty 0,5. V stĺpci "B" bola postupnosť vytvorená tiahnutím myšou. Nechápen ako Calc dospel k takýmto výsledkom. Robí to ajv AOO aj v LO s nastavenými iteráciami aj bez nich. Stretol sa už niekto s tým?

S%C4%8D%C3%ADt_Calc.png
_______________________________________

;o)

Editoval sedlacekdan (4. 1. 2013 19:50:31)

neutr · 26. 12. 2012 12:49:40

Velice zajímavé a také alarmující. Důvodem bude hranice 10^18, za kterou už počítač zaokrouhluje. Ve sloupci "A" jako kdyby "odečítal" a ve sloupci "B" jako kdyby přičítal. Celkově 22 pozic je určitě za hranicí schopnosti počítat "přesně". To ale nevysvětluje proč se chová odlišně když použijeme vzorec, nebo tažení (kopírování tažením).

Je tedy otázkou nač je potřeba tak velká čísla. Další věcí je to, že se může různá architektura počítače chovat různě. Výpočty dělá koprocesor. Takže je možné, že co deska, to jiný výpočet. Nedivil bych se když by jste měl vícejádrový procesor a každý dělal něco trošku jiného. Nicméně možná půjde jen o bity. Stroj sčítá binárně a OOo je na 32- bitech. Problém vypadá, že jednou jde o rekurzi a podruhé o iteraci bitových čísel. Desetinná čárka je jen relativní tedy správně "plovoucí" záležitostí. Dost možná by takovou rotiku udělal 64 bitový systém.

Vysvětlit to neumím, ale domnívám se, že by oba systémy měly dávat stejný výsledek - tedy i stejnou chybu.

PetrValach · 26. 12. 2012 17:05:21

32bit, Ubuntu, LO 3.6.4 - ještě daleko šílenější výsledek :-))))

No páni tohle jsem jaksi nečekal...

strepon · 26. 12. 2012 19:19:31

Tohle se dá těžko považovat za chybu – číslo, v tomhle případě nejspíš typ double, je reprezentován určitým omezeným kusem paměti, a nemůže mít proto neomezenou přesnost, tady bude hranicí oněch 15 číslic. Vliv na výsledek bude mít určitě algoritmus výpočtu (proto asi rozdíly mezi oběma sloupci), kompilátor, procesor… Nejjednodušší je smířit se s tím, že pro výpočty s vyšší přesností je potřeba něco jiného než Calc:))

neutr · 26. 12. 2012 19:47:31

Jenom bych ještě dodal, že přesného výpočtu lze docílit i daleko za hranicí přesného výpočtu v jedné frontě. Použije se "klasické" počítání s polynomy. Potom tedy například do každé buňky vložíme trojmístné číslo. Tyto pak sčítáme ap. podle řádu. Není to nic extra, ale je to řešení. Ve výsledku pak musíme spojit do string-u, pokud chceme číslo v "jednom kuse".

PetrValach · 26. 12. 2012 20:25:27

Pánové, nerozumím tomu vlastně skoro vůbec, myslím, jakým způsobem komp dopočítává ty hodnoty, ale na Excelu 2007 není problém... klidně dohodím screen. Excel počítá max. na 30 míst a všechn buňky jsou perfektní.

Teď zkouším ještě jednou Calc a zdá se být vše OK. Nástroje|Možnosti|Calc|Vzorce|Podrobné nastavení výpočtů - není tohle řešením?

Editoval PetrValach (26. 12. 2012 20:30:00)

Roman Toman · 26. 12. 2012 23:25:21

neutr napsal(a)

Velice zajímavé a také alarmující. Důvodem bude hranice 10^18, za kterou už počítač zaokrouhluje. Ve sloupci "A" jako kdyby "odečítal" a ve sloupci "B" jako kdyby přičítal. Celkově 22 pozic je určitě za hranicí schopnosti počítat "přesně". To ale nevysvětluje proč se chová odlišně když použijeme vzorec, nebo tažení (kopírování tažením).

Bral by som to, keby vzorec obsahoval nejaký komplikovaný mnohooperačný výpočet, ale tu sa jedná len o pripočítanie jednej jedinej desatiny. Ešte na margo toho pripočítavania. Na obrázku je len časť tabuľky. Hodnoty pokračujú až do hodnoty 100 po jednej desatine. Odchýlka výpočtu v stĺpci "A" nie je rovnaká, niekde uberie, niekde pripočíta. V stĺpci "B", ktorý je tiahnutý myšou len pripočítava tú jednu stobiliontinu.

neutr napsal(a)

Je tedy otázkou nač je potřeba tak velká čísla.

Nie sú potrebné. Formát čísiel som si nastavil len pre kontrolu, keď som NÁHODOU niekde uprostred tabuľky myšou klikol do bunky a táto divná hodnota sa mi objavila v zadávacom poli(v bunke bolo zobrazenie normálne). Bunky som mal pôvodne nastavené na základný číselný formát a až potom som ich nastavil na max. počet desatinných miest (20) a nestačil som sa diviť. A propó, nemám viacjadrový procesor, stále bežím na dedkovi Celeronovi a na 32-kových XP.

strepon napsal(a)

Tohle se dá těžko považovat za chybu – číslo, v tomhle případě nejspíš typ double, je reprezentován určitým omezeným kusem paměti, a nemůže mít proto neomezenou přesnost, tady bude hranicí oněch 15 číslic. Vliv na výsledek bude mít určitě algoritmus výpočtu (proto asi rozdíly mezi oběma sloupci), kompilátor, procesor…

Ako som už napísal vyššie bral by som to pri delení, logaritmoch, odmocninách a podobných operáciách, ale rozhodne nie pri pripočítavaní jednej desatiny. S taku presnosťou to dokážem aj na guličkovom počítadle.

PetrValach napsal(a)

Teď zkouším ještě jednou Calc a zdá se být vše OK. Nástroje|Možnosti|Calc|Vzorce|Podrobné nastavení výpočtů - není tohle řešením?

Toto nastavenie nemá na výsledok skoro nijaký vplyv. Skúšané aj so studeným reštartom LO.

strepon · 27. 12. 2012 19:20:18

Pro zájemce odkaz na diskusi k tématu v bugzille LO:
https://bugs.freedesktop.org/show_bug.cgi?id=37923
Je tam taky ukázka toho, že a-b-c není totéž jako a-c-b.

Roman Toman · 27. 12. 2012 20:41:19

strepon napsal(a)

Pro zájemce odkaz na diskusi k tématu v bugzille LO:
https://bugs.freedesktop.org/show_bug.cgi?id=37923
Je tam taky ukázka toho, že a-b-c není totéž jako a-c-b.

Pravda, pravda. Lenže to, že a-b-c ≠ a-c-b platí len pri odpočítavaní (teraz beriem v potaz len tieto dve matematické operácie, sčítanie a odčítanie). Lenže môj problém sa týkal pripočítavania hodnoty a pri pripočítavaní hodnoty je to úplne jedno v akom poradí sa hodnoty sčítajú.

A vo vzorovom zošite (z odkazu) sa jedná práve o ukážku odpočítavania a tiež je to zaujímavé. Výsledok prvého riadku by mal byť správne -1 a je 0, a to dokonca aj po čiastkových výpočtoch. Z nejakého mne neznámeho dôvodu vzorec zareaguje až na zmenu čísla 1 na 3 a výsledok ukáže správne -3. Dvojku ešte ignoruje. No a keďže sa jedná o celé a nie desatinné čísla, tak je to hrubá chyba, ktorá nemá v takomto serióznom programe čo robiť.

Editoval Roman Toman (27. 12. 2012 20:43:40)

OpenOffice.cz - web věnovaný kancelářským balíkům OpenOffice.org

#1 26. 12. 2012 11:56:20

?Sčítanie? v CALCu - CHYBA LO/OO

#2 26. 12. 2012 12:49:40

Re: ?Sčítanie? v CALCu - CHYBA LO/OO

#3 26. 12. 2012 17:05:21

Re: ?Sčítanie? v CALCu - CHYBA LO/OO

#4 26. 12. 2012 19:19:31

Re: ?Sčítanie? v CALCu - CHYBA LO/OO

#5 26. 12. 2012 19:47:31

Re: ?Sčítanie? v CALCu - CHYBA LO/OO

#6 26. 12. 2012 20:25:27

Re: ?Sčítanie? v CALCu - CHYBA LO/OO

#7 26. 12. 2012 23:25:21

Re: ?Sčítanie? v CALCu - CHYBA LO/OO

#8 27. 12. 2012 19:20:18

Re: ?Sčítanie? v CALCu - CHYBA LO/OO

#9 27. 12. 2012 20:41:19

Re: ?Sčítanie? v CALCu - CHYBA LO/OO

Zápatí