On 2019-06-19 11:45, J.F. wrote:
> Użytkownik "AK"  napisał w wiadomości grup
> dyskusyjnych:qeckl4$1nvk$...@g...aioe.org...
> On 2019-06-17 16:09, J.F. wrote:
>>> Dzisiejsze koprocesory ciagle maja ten sam format liczby double,
>>> ktory powoduje te błędy.
>
>> Taaa? A zauwazyl Ty ze "przy okazji" posiadaja jeden z formatow dluzszy
>> niz najdluzszy int (czyli 80bit)?
>> Czyli moze liczyc w wiekszym zakresie :)
>
> Bez znaczenia - problem ciagle ten sam.

Nie. Obliczenia posrednie (wewnetrznie robione na np 80 bitach)
sa dokladniejsze, wiec koncowy wynik tez (lepiej/dokladniej
obcinany/zaokraglany)

> Nawiasem mowiac - czy mi sie wydaje, czy ten format 80-bit jest po
> cichutku wycofywany ?

A nie wiem. I.. chce nie wiedziec.
Ba! Wlasnie umiejetnosc poslugiwania sie fp polega na..
"nicniewiedzeniu" o ich faktycznej reprezentacji.

>>> Wczorajsze koprocesory mialy formaty BCD, ktore akurat pieniadze
>>> liczyly dokladnie, czy dzisiejsze maja to juz nie wiem.
>
>> Kolejny mit, ze BD jest "zbawieniem na cale zlo".
>
> Nie, ale czesto ulatwia.

Tak, ale w przypadku "surowych" dziesietnych czyli nie bedacych
wynikiem/uczestniczacych w obliczeniach. A ilez takich?
Nawet w bankowosci dosc malo.

>> PS: "My" akurat w defBank-u stosowalismy zwykle double i jakos Assecco
>> sie z tego powodu do dzis nie przekrecilo :)
>
> A kto zgarnial "cwierccentowki Dextera" ? :-)

Jamci... :)

> Ze wspomnien starszego informatyka ... bankowego.
> "Fortran, co to za g* jest.  Klient ma na koncie 25.60, przychodzi  mu
> 74.40,
> i na koncie ma 99.999996
> Przeszlismy na podwojna precyzje. To teraz ma
> 99.999999999954
> "
Zgoda, jeno cus mi sie wydaje ze to dosc mlody osesek psioczyl na ten
Fortran ;)

AK