Vlákno názorů k článku Kouzlo datových typů Decimal32, Decimal64 a Decimal128 od jdsulin - Typ Decimal je bez adekvátní podpory v HW...

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.