Vlákno názorů k článku Užitečné funkce a makra ze standardní knihovny Rustu od wamba - Tak nějak mě matou f64::INFINITY, f64::NEG_INFINITY, f64::NAN, předpokládal...
-
Pavel TišnovskýZlatý podporovatelOny to jsou ve skutečnosti hodnoty, s nimiž spousta funkcí a operací počítá (podle IEEE 754), takže je známé, jaký bude výsledek. Problémy mohou nastat při vstupu a výstupu - některé funkce s těmi hodnoty pracují (format/println vypíše NaN atd.), ale na vstupu to může být horší (já to řešil u JSONu například).
-
arm (neregistrovaný)
Pro integery je to horší, protože tam neexistují žádné rezervované hodnoty tak, jako u floatu nebo double. Takže jsou tam problémy typu:
1) přetečení
2) podtečení
3) přenos
4) dělení nulou
5) dělení nuly nulouVětšina CPU to do nějaké míry řeší použitím příznaků a u dělení ještě výjimkou. Ale samotný formát s tím nepočítá!
-
Miloslav Ponkrác (neregistrovaný)
A polovina toho, co píšete, má problém i ve floatech. Protože float má pouhé 3 speciální typy hodnot (spíše rozsahy): NaN a dvě nekonečna.
Pokud nebudete číst příznaky od FPU, které detekuje různé výjimky, tak leccos nepoznáte. V tom je to stejné jako u int.
Například poznáte, proč je výsledek float operace NaN? To může být stejně jako 0/0, nebo ln(-2), nebo sqrt(-2), nebo nekonečně dalších možností.
Pokusy přidat příznaky a další informace do float hodnot, což typicky odneslo NaN, protože to není jediné číslo ale obrovský rozsah mnoha hodnot. Takže mám signaled NaN a quiet NaN - a pokud se pokusíte uložit do proměnné hodnotu signaled NaN, tak vám ji automaticky změní na quiet NaN a teoreticky se vyvolá výjimka či přerušení. Takové vyfikundace i int nejsou, že se vám samovolně změní hodnota čísla, aniž by proběhla jakákoli aritmetická operace.
NaN také může nést číslo se zprávou o tom, co se stalo, protože je uloženo do nevyužité mantisy.
Na druhé straně vám nikdo nebrání si i na intech potřebné tři hodnoty dodefinovat. Například x86 FPU si pro int počítání dodefinovává, že NaN pro inty je nejmenší záporné číslo reprezentované daným typem.Když si třeba pro 32bitový int dodefinujete, že -2**31 je NaN, -2**31+1 je mínus nekonečno, +2**31-1 je plus nekonečno, snadno si vytvoříte stejnou aritmetiku, jako je u floutů včetně těchto tří speciálních stavů.
Zkrátka co si nadefinujete, to máte. U floutů stejně 99 % knihoven a programů je v háji, jakmile se jim tam objeví zcela standarníd hodnota NaN nebo Infinity. Počítají pouze s finálními validními float čísly.
-
ARM (neregistrovaný)
Proč je výsledek NaN poznám, protože u každé funkce/operace je popsáno, za jakých okolností NaN vrací a můžu si to ošetřit - pokud potřebuji.
Já mám IEEE 754 rád ne proto, že je dokonalé (není :-), ale protože umožňuje i lidem, co o FP moc neví, psát relativně robustní programy (proto je navrženo tak, jak je navrženo). S FX nebo asi dalšími deseti dalšími formáty FP by bylo _daleko_ víc problémů. Samozřejmě FP nezaručuje asocitativitu atd., ale kupodivu málokdo s tím má větší problémy. Snad jen nemožnost reprezentovat 0,1 přesně je dost na obtíž, ale tady začíná jedna z hranic mezi programátory a pojídači koláčů :-)
-
Miloslav Ponkrác (neregistrovaný)
Pokud máte podprogram/funkci, která dělá sadu operací - a vyplivne NaN, tak poznáte víceméně kulové.
IEEE754 je jeden z nejlépe navržených standardů v IT vůbec (na opačné straně extrému s nejhoršími standardy považuji veškerou práci W3C).
Float toho nezaručuje více. Například nezaručuje ani to, že výsledek stejné operace s dvěma stejnými čísly dopadne pokaždé stejně.
Právě tam, kde potřebujete přesnou reprezentaci těch 0,1 nasadí opravdový programátor fixed point čísla. Právě proto existují různé formáty čísel. Pojídač koláčů nasadí floating point čísla a pak sofistikovaně řeší různé problémy, a je na sebe hrdý, že není pojídačem koláčů, protože si dělá věci zbytečně složité - image a pěstování dojmu především.
Různé formáty čísel řeší DOBRÝ programovací jazyk, a problémy vezme na sebe tak, že programátor řeší jen minimum rozdílů a věcí. Programátor nemá řešit strojovou reprezentaci a její detaily jinak, než zvolením vhodného datového typu a jeho rozsahu. Pokud musí větší detaily formátu nějakého čísla zásadněji řešit programátor, je na čase změnit programovací jazyk na některý, který je možné méně hype, ale o to více řeší to, co programovací jazyky řešit mají.
