Dnia Tue, 25 Jun 2019 21:48:04 +0200, AK napisał(a):
> On 2019-06-19 11:45, J.F. wrote:
>> Użytkownik "AK"  napisał w wiadomości grup
>> 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)

Ale nadal 31.8 nie da sie zapisac dokladnie.

>> 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.

Ale musisz umiec dobrac EPS :-)

>>>> 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.

Wydaje mi sie, ze w bankowosci wiekszosc.

>> 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 ;)

Albo doswiadczony :-)

Akurat patrze na program magazynowy - ma dwie jednostki.
Moze np farbe liczyc w litrach, albo w puszkach.
Jak puszka ma 3 litry to sie dzieja cuda.

J.