Názory k článku Kouzlo datových typů Decimal32, Decimal64 a Decimal128

Typ Decimal je bez adekvátní podpory v HW naprosto zbytecny. Je samozrejme potreba na problemy single a double myslet a nikdy je neporovnavat. Jenomze resit problem, ze v nich nelze reprezentovat 0.1 presne je uplne stejne, jako resit problem, ze nejde reprezentovat 0.33333...peri­odickych v desitkovem zapisu a zatim jsem nevidel standard, ktery by pozadoval zaklad v mantise 3 misto 2 nebo 10. Racionalnich cisel je nekonecne mnoho mezi 0 a 1 iracionalnich jeste vic, takze zadny standard to proste nezvladne. Akorat je fakt, ze 0.1 je proste takove pro lidi pouzivane a pochopitelne. Kdyz ale potrebujes x desetinnych mist, tak je podle me jednodussi pouzit obycejne int32/64 a posunout desetinnou carku, ale i to ma samozrejme nevyhody, napr. operace deleni.
Kazdopadne zajimavy clanek, znat tyhle zakouti single a double drive, usetril bych si spoustu casu :)

nojo ale jak vyřešíš ty problémy s 0,1, 0,01 apod. (s prakticky všemi desetinnými místy)? Ono se zmiňuje finančnictví, ale je to i jinde, třeba výpočty vzdáleností, délek prakticky všude atd. Jako problém je pochopitelně v tom, že používáme desítkovou soustavu, ale tak to prostě je :-)

Na druhou stranu zrovna v tom účetnictví to nejsou tak brutální výpočty, aby to nedalo čisté SW. A # jazyky mají typ Decimal snad už od dob Visual Basicu blahé paměti (NEvzpomínáme v dobrém, ale toto bylo fajn).

Jinak řešením je fixed-point s desítkovou čárkou, ale to taky nemá HW podporu.

Délky nejsou problém ani s floatem, pokud nesčítáte malé a velké vzdálenosti (1e6 + 0.0001). NASA samotná třeba při výpočtech použivá Pi s přesností na 15 nebo méně míst.

https://www.jpl.nasa.gov/edu/news/2016/3/16/how-many-decimals-of-pi-do-we-really-need/

U peněz je hlavním problémem zaokrouhlování, protože vymýšlí nebo ztrácí peníze. A to lidé nemají rádi.

Ten priklad s NASA neni vhodny.
Napriklad nejlepsi etalony casu se meri s relativnima nejistotama i 10^(-18). Neboli potrebuji reprezentovat cisla s 20 ciframa minimalne. Vypocet se sice vetsinou dela v odchylkach, ale ne vzdy to jde takhle zjednodusit.

15 desetinných míst bylo zmíněno u Pi. To používáš převážně u vzdálenosti. A v případě této přesnosti ti umožňuje operovat s přesností na centimetry u objektů v řádově stejné vzdálenosti jako je Pluto v afeheliu.

no na masinach, ktere si napriklad berou nejaky vlakno nebo drat (a nejak to potom strihaji a pouzivaji) se ta chyba nascita i za jedinou smenu. A na konci dne masina rekne: "zitra potrebuju 5.8 civek". Tak tady je to jasny, zaokrouhli se to nahoru (a na konci roku se to bude vysvetlovat ucetni, jaktoze to nakonec nesedi), ale u 5.2 se vsichni jen skrabou na hlave.

Pí zase takovej problém není.
Ale co si pamatuju, tak kdysi se třeba na Aldebaranu řešilo takové téma, kterak numericky počítat pohyb planety, aby se v ideálním případě (jediná planeta v Newtonově mechanice, kolem pevného Slunce, prostě na ověření správnosti) po jednom oběhu trefila tam, odkud začala.

Případně nověji, na sčítání velkého s malým se dá celkem rychle narazit už když si člověk hraje s backpropagací v neuronce...

To je obecne problem numerickych vypoctu, tam ti chyba vetsinou narusta (ne vzdycky samozrejme). Ale jestli ti narusta v decimal nebo double reprezentaci je celkem jedno.

V takovem pripade zacnes pocitat v halerich nebo v nejmensi mozne delitelnosti toho co potrebujes a navic neztratis HW podporu u zakladnich operaci.
Co se tyka delek, tak double ma uplne stejny problem jako jakakoliv jina reprezentace. Kdyz mas pravouhly trojuhelnik o odvesnach 1m a 1m, tam mas docela problem s delkou prepony. Teoreticky bys mohl udelat reprezentaci, kde by byl zaklad sqrt(2), ale to bys zase mel problemy reprezentavat neco jineho, co neni nasobkem sqrt(2).

Mimochodem kdyby se v tech prikladech u single/ deouble pokazde vysledek zaokrouhloval vynasobenim 10ti, prevedenim na int a vydelenim 10ti, tak se ta chyba scitat nebude. Nerikam, ze to je dobre reseni zrovna tehle situace. Ale i v delkach / souradnicich se toto pouziva, proste potrebujes dostat ten single/double na nejakou pozici v gridu. Taky ti samozrejme dojde drive rozsah single / double.

Copak Visual, už DOSový QuickBasic měl typ Currency, který počítal desítkově s přesností na čtyři desetinná místa.

Nesouhlasím. Typ Decimal je buďto zbytečný sám o sobě nebo má nějaké nevýhody, když nemá podporu přímo v hardware. Nelze říci, že jeho případná zbytečnost vyplývá z pomalejšího výpočtu oproti floatům.

IBM má hardwarovou decimální jednotku od POWER7. Ano, jedna decimální a 4 klasické floating point v double precision (https://en.wikipedia.org/wiki/POWER7).

Jinak nízkoúrovňová implementace nevypadá tak zle: https://www.crockford.com/dec64.html

Decimal není zbytečný. Je specializovaný na čísla "vycucaná z prstu", takže primárně finance a podobně. Problém s 0.3... nemusíme řešit, protože lidi si samozřejmě cucají z prstu čísla, co vypadají pěkně v desítkové soustavě.

Druhá věc je užitečnost decimal32 a 64. Co jsem viděl, tak ve chvíli kdy dává smysl použít decimal, tak to byl vždycky ten 128.

Doplním, že Decimal (užitečný např. pro finance) má už Turbo Pascal pro DOS:

Type Range Significant digits Size3.2
Single 1.5E-45 .. 3.4E38 7-8 4
Real 5.0E-324 .. 1.7E308 15-16 8
Double 5.0E-324 .. 1.7E308 15-16 8
Extended 1.9E-4951 .. 1.1E4932 19-20 10
Comp -2E64+1 .. 2E63-1 19-20 8

The Comp type is, in effect, a 64-bit integer.

https://www.math.uni-leipzig.de/pool/tuts/FreePascal/ref/node6.html

EDIT:
"Typ Decimal je buďto zbytečný sám o sobě nebo má nějaké nevýhody, když nemá podporu přímo v hardware"

Decimal má podporu v HW. Však je to integer.

9. 4. 2024, 13:56 editováno autorem komentáře

Decimal, ktery mas na mysli ty ano, decimal, o kterem je rec v clanku ne.

V bankách sa väčšina výpočtov robí v Decimal. Inak by nevyšla uzávierka. Aktíva sa musia rovnať pasívam a float/double zaokrúhľovanie chyby by robili problémy.
Procesory POWER preto majú HW jednotky na decimal aritmetiku, bolo by zaujímavé spustiť benchmark aj na nich.

Jen drobounká OT poznámka k tomu, že ve finanční sféře se počítání se základem 2 neujalo: to není tak úplně pravda.
Sice máme peníze pěkně v desítkové soustavě, ale nikoliv v řadě 1-10-100 (koruna, desetikoruna, stokoruna), ale od každé je ještě polovina a dvojnásobek (padesátihaléř+dvou­koruna, pětikoruna+dva­cetikoruna, padesátikoruna+dvou­stovka...).
Ejhle, střípek dvojkové soustavy... ;o)

To není střípek dvojkové soustavy. Polovina není omezená na dvojkovou soustavu. Jestli hledáte zbytky jiných soustav, tak spíš koukejte po dvanáctkové. Dál potkáte zbytky pětkové, dvacítkové a šedesátkové.

Dvojková soustava je extrémně nepraktická.

Tohle (půlka a dvojnásobek) tam zůstalo pravděpodobně po Egypťanech, a jejich počítání vážením. Oni opravdu počítali (násobili) postupem, který má k té dvojkové soustavě blízko. A rozhodně bych si netroufl ho nazvat nepraktickým.
Ta dvanáctková a podobné soustavy při počítání peněz jsou mnohem mladší. Tucet lze totiž snadno rozdělit na polovinu, třetinu, čtvrtinu či šestinu. Kopu pak i na pětiny a desetiny.
Tyhle pozůstatky se leckde najdou taky (že, Angličani...).

Jen tak nějak vyhráli ti, co na prstech na rukou dopočítají do desíti, nad těmi, komu ty prsty stačí až do 1024. ;oD

No od dělení a násobení dvěma je k dvojkové soustavě zhruba stejně daleko jako k jakékoliv jiné soustavě se sudou bází. Však to taky dělali v desítkové a ne v dvojkové soustavě.

A proč vyhráli ti, co napočítají do deseti (případně do 12 na jedné ruce) je docela jasné. :D

Jak (prý) pravil Gauss: Hlupáků i chytráků je v populaci zhruba stejně - jen ti hlupáci jsou víc vidět a slyšet.

no nejenom Anglicani. I my si uzivame 12/24 soustavy u casu zkombinovane s 60kovou (i kdyz to Francouzi za revoluce chteli prevest na desitkovou). Taky bohudik mame 360 stupnu a ne pitomych 400.

Jinak (ale to se asi vi) "dozen" taky znamena 12 a dneska se pouziva uplne v obecne rovine.

Tak zrovna ty stupně jsou pěkně na houbelec, když z toho pak vyleze metrika s iracionální konstantou (ds^2 = dr^2 + (r*pi/180 dfi)^2, takže stejně se většina výpočtů dělá v radiánech, což vede k ještě většímu zmatení méně znalých.

ale holt člověk nemůže chtít všechno.

Těch (francouzských) 400 stupňů se používá běžně, například geodeti nebo dělostřelci v tom jeli odjakživa. Jen obyčejní smrtelníci musí vystačit se 360 :-D

Předně: 1023, hrubá chyba... a navíc některé kombinace jsou prstolomné ;-)

Omluva, hloupá chyba.
Ale nacvičené je mám všechny, běžně to používám jako čítač pro měření času nebo vzdálenosti (počet kroků).

Ono to není ještě tak dlouho co se vyskytoval i pětadvacetihaléř, ale kdosi vypočítal, že z kombinace 1-2-5 se dá poskládat jakákoliv libovolná částka při nejmenším nutném počtu mincí a bankovek v oběhu, tak se to ujalo. Se dvojkovou soustavou to nemá nic společného, jde čistě o finanční náklady na výrobu platidel.

V tom máte naprostou pravdu.
Jen s tím dodatkem, že právě ten kus dvojkové soustavy způsobuje to, že ten počet je skoro optimální.
Čistě dvojková řada by znamenala, že nepotřebujete více, než jedno platidlo od každé hodnoty. V řadě 1-2-5 (0.5-1-2) vždy potřebujete pro některé hodnoty dvě platidla (mince, bankovky).
Ve skutečnosti byl ten pětadvacetihaléř (ještě ho mám schovanej!) výhodnější, ale dalším krokem by byla hodnota 12.5 haléřr, což je nesmysl, protože desetník je dostatečně blízko. Nicméně tenkrát byla ta řada směrem dolů: pětihaléř, tříhaléř (zaokrohlené 2.5 - ještě ho mám schovanej) a jednohaléř. Jak vidno, od koruny dolů to opravdu šlo po binární řadě, byť se zaokrouhlením na integer.

Tohle je moc zajímavý problém.
Chci říct, že se mýlíte, ale je to pochopitelné, protože realita je relativně neintuitivní.
Minimální počet mincí bychom měli, kdybychom počítali v TROJKOVÉ SOUSTAVĚ.
Na to přišlo už dávno .. trojka je totiž nejblíž jednomu zajímavému číslu, které se stalo základem logaritmů.
Rusové na tom postavili digitální počítač.
Tam to bylo vůbec nejzajímavější, protože operace v symetrické trojkové soustavě jsou rychlejší. Akorát měli (tenkrát) problém s neefektivitou paměti, tak se to neujalo. Ale mohlo by to být zajímavé.
https://cs.wikipedia.org/wiki/Balancovan%C3%A1_trojkov%C3%A1_soustava
Mělo to určitou estetickou krásu, protože čísla se dala zapsat (místo 0 a 1) pomocí symbolů "- 0 +" a číslo se dá negovat prostou záměnou mínus za plus a naopak

Základ co nejblíž 2.7 optimalizuje jednu metriku - počet číslic krát počet jejich druhů. Jestli je tahle metrika vhodná pro nějaké konkrétní použití je druhá otázka. Třeba pro návrh telefonní plechové huby asi jo. Ten počet otázek krát počet možností si musíme vyslechnout.

Na druhou stranu pro počítání tahle metrika IMO moc vhodná není. Vypadá to, že větší počet číslic je pro naše mozky výrazně větší záhul než větší báze. Proto taky obvykle používáme hexa čísla místo binárních.

A i hardware často používá vyšší báze než 2 - třeba MLC flashky, nebo víceúrovňová modulace v PCIe.

To věděli už staří Řekové a Římani (a kdoví, kdo před nimi) :-)
https://en.wikipedia.org/wiki/Abacus
https://en.wikipedia.org/wiki/Bi-quinary_coded_decimal
https://en.wikipedia.org/wiki/Salamis_Tablet

A na té desce ze Salmíny možná používali i záporný hodnoty cifer v řádech, i když to se bez pamětníků dost špatně dokazuje. Ony ani ty římský číslice nejsou zase tak hrozný vynález, protože se moc nepoužívaly na výpočty, ale jenom na storage (na počítání měli abacus) a byly optimalizovaný na rychlý a jednoduchý přepisování mezi úložištěm a výpočetní jednotkou.

Díky za zajímavý článek!

fajn opáčko - float/double - jeho přednosti a nedostatky, by měl mít na paměti každý vývojář.

Obecně float/double mají problém s porovnáváním typické 0.1 + 0.2 == 0.3 neplatí, to je asi ta nejzásadnější věc na co musí člověk dávat pozor.
Ale protože je práce s nimi tak rychlá, tak se používají stejně všude možně i ve hrách.

Také se stává, že žádné decimal typy nejsou ani k dispozici typicky Javascript - má jen double.

Zlatý Cobol a jeho deklarace ve stylu PIC S9(12)V99

nebo SQL s NUMERIC(p, s)

Tak ten počítal desítkově "od přírody", ne?

Super článok. Akurát to riešim vo svojom projekte.