AK wrote:

> Uj nie mam pojecia co to jest :(

https://en.wikipedia.org/wiki/Cascaded_integrator%E2
%80%93comb_filter

Genialnie "wchodzą" w FPGA i inny sprzęt, w software nieco słabiej.
Pół świata na tym stoi, na 100% masz np. w telefonie.

Pozdrawiam, Piotr

do góry

W dniu 2019-06-13 o 23:22, bartekltg pisze:
> On Thursday, June 13, 2019 at 3:37:52 PM UTC+2, Pszemol wrote:
>> "Mateusz Viste" <m...@n...pamietam> wrote in message
>> news:5d00f035$0$15194$426a74cc@news.free.fr...
>>> On Wed, 12 Jun 2019 07:17:45 -0500, Pszemol wrote:
>>>> Pisząc w Visual Basic 6 gostek porównywał rezultat konwersji CDbl()
>>>> stringu od którego odjął stałą numeryczną 1.8 do lokalnej zmiennej
>>>> double.
>>>
>>> Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
>
> Pieprzenie. No, czyba, że programowanie = frontend.

nie da się, w webówce np część języków wszystkie liczby to
zmiennoprzecinkowe

--
http://kaczus.ppa.pl

do góry

Użytkownik "AK" napisał w wiadomości grup
dyskusyjnych:qecl7l$1qds$...@g...aioe.org...
On 2019-06-17 16:20, J.F. wrote:
>>>>> Czy inne Visuale jak VC++ lub VC# też tak mają?
>>>> To jest problem procesora z FP IEEEcostam.
>>> Wcale nie. To jest problem jak najbardziej ogolny.
>
>> Ogolny, ale te formaty, co wewnetrznie uzywaja liczb z mantysą
>> binarna, to maja problem z liczbami dziesietnymi.

>A te (a byly/sa takie) ktore uzywaja wewnetrznie systemu dziesietnego
>maja rownie powazne problemy z danymi binarnymi.
>Zaden argument.

No ale liczby dziesietne ludzie uzywaja nagminnie, a liczb binarnych
zmiennoprzecinkowych ... to nawet programisci nie uzywaja :-)

Zdarzylo Ci sie kiedys okreslic, ze to by bylo dobrze przemnozyc
przez
11.01101

?

>PS: Kto k.. skrosowal ten watek?!

Nie ja.

J.

do góry

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.

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

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

>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" ? :-)

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
"

J.

do góry

On Wed, 19 Jun 2019 11:45:24 +0200, J.F. wrote:
> 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 "

Dobre :)

A na problem - mimo że powszechnie znany - jednak ciągle nadziewają się
nowi. Dziwne, że w banku (wydawałoby się, poważnej instytucji) w to
wpadają.

Ciekawostka - GnuCash z tego powodu wiele lat temu zrezygnował z float na
rzecz stałego przecinka: http://www.gnucash.org/docs/v1.6/C/t7204.html

Mateusz

do góry

W dniu 19.06.2019 o 13:40, Mateusz Viste pisze:
> On Wed, 19 Jun 2019 11:45:24 +0200, J.F. wrote:
>> 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 "
>
> Dobre :)
>
> A na problem - mimo że powszechnie znany - jednak ciągle nadziewają się
> nowi. Dziwne, że w banku (wydawałoby się, poważnej instytucji) w to
> wpadają.
>
>
> Mateusz
>

Nowi jak nowi, ale żeby wojsko... I niestety były ofiary.

http://www-users.math.umn.edu/~arnold//disasters/pat
riot.html


KLoSS

do góry

"AK" <n...@n...net> wrote in message
news:qe665k$18po$2@gioia.aioe.org...
> On 2019-06-13 15:37, Pszemol wrote:
>> "Mateusz Viste" <m...@n...pamietam> wrote in message
>> news:5d00f035$0$15194$426a74cc@news.free.fr...
>>> On Wed, 12 Jun 2019 07:17:45 -0500, Pszemol wrote:
>>>> Pisząc w Visual Basic 6 gostek porównywał rezultat konwersji CDbl()
>>>> stringu od którego odjął stałą numeryczną 1.8 do lokalnej zmiennej
>>>> double.
>>>
>>> Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
>>
>> Faktem jest, że gdy zmienne nie skaczą dynamicznie od e-15 do e+15 to
>> warto znaleźć zakres wariacji mierzonej zmiennej, oczekwianą dokładność
>> i zamiast na float operować na long integer * 10000 na przykład...
>
> 1. ile masz takich przypadkow w zyciu (owszem, fraktale).

W konkretnych zastosowaniach przemysłowych? Embedded?
Bardzo dużo.

> 2. przy dzisiejszych koprocesorach ? Na pewno warto ?
> /Kiedys zdecydowanie tak, wiec absolutnie podejscia nie potępiam/.

A co ma koprocesor tutaj do rzeczy?

do góry

W dniu 2019-06-12 o 17:27, J.F. pisze:

>> Weź chłopie ić na studia (ja miałem to nawet na wieczorowych 20 lat temu) i się
doucz! Zamiast
>> zadawać głupie pytania. Choć gdybyś dłubał w czymś innym niż VB to byś wiedział o
problemie (w
>> każdej książce do Asemblera czy C czy C++ to powinno być).
>
> Musialbym sobie przypomniec ... ale przy okazji Assemblera raczej nikt nie poruszal
takiego watku.
> Przy C predzej, ale to gdzies na pograniczu.

Na studiach jest (powinien być?) cały przedmiot o nazwie "Arytmetyka maszyn
cyfrowych",
gdzie na kilkudziesięciu godzinach wykładów można dokładnie dowiedzieć się, jak są
pamiętane liczby całkowite ze znakiem, bez znaku, zmiennoprzecinkowe, dlaczego i
kiedy
występują błędy zaokrągleń itp. Można też dowiedzieć się, że warunek
"jeśli a jest równe b" przy rzeczywistych typach a, b to proszenie się o kłopoty.

Problemy nie zależą od języka programowania. Ułamka dziesiętnego 0.8 nie da się
w przyjętym sposobie zapisu liczb zmiennoprzecinkowych zapisać dokładnie - w układzie
dwójkowym jest to ułamek okresowy, ma nieskończenie wiele znaczących cyfr.
Nie można ich wszystkich pamiętać. Oczywistym rozwiązaniem pozwalającym uniknąć
błędów jest używanie tylko liczb całkowitych. Np. jeśli ma to być jakaś
kwota pieniędzy, należy liczyć w groszach (zawsze całkowitych), a nie złotówkach
i ułamkach złotego.

P.

do góry

On Thu, 20 Jun 2019 14:16:12 +0200, Piotrne wrote:
> Np. jeśli ma to być jakaś kwota pieniędzy, należy liczyć w groszach
> (zawsze całkowitych), a nie złotówkach i ułamkach złotego.

Tymczasem akcje Ursusa stoją po 0.797 zł. :)

Mateusz

do góry

W dniu 2019-06-20 o 14:16, Piotrne pisze:
> W dniu 2019-06-12 o 17:27, J.F. pisze:
> Oczywistym rozwiązaniem pozwalającym uniknąć
> błędów jest używanie tylko liczb całkowitych. Np. jeśli ma to być jakaś
> kwota pieniędzy, należy liczyć w groszach (zawsze całkowitych), a nie złotówkach
> i ułamkach złotego.
Masz teoretycznie rację ale to jakiego typu zmiennej używasz zależy od
języka, np w takim Cliperze 5.3
w którym w latach 90 popełniłem kilka programów liczących pieniądze jest
zmienna INT
ale w praniu wyszło że jest ona typu float :( i z problemem opisanym
przez Przemol-a musiałem się wtedy już zmierzyć, dodawałem tysięczne
części grosza na końcu przed samym porównaniem.


--
Janusz

do góry