On 2019-06-20 14:16, Piotrne wrote:
> 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.

Swieta racja.

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

J/w.

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

Nie, gdyz policzenie nawet zwyklej sredniej moze sie okazac problemem.
Moze sie okazac ze obliczenie jej na dwojkowych floatach jest blizsze
rzeczywistosci niz na groszach, bcd czy czymkolwiek innym.

AK

do góry

On Tue, 25 Jun 2019 21:32:56 +0200, AK wrote:
> On 2019-06-19 09:03, Mateusz Viste wrote:
>>> No dobra...
>>> Bo piszą np. potem takie z gruntu błędne konstrukcje.
>>>
>>> int a = cus_tak;
>>>
>>> if ( x & 0xFFDF )
>>
>> I to jest argument za tym, by nigdy nie zakładać że typ zmiennej jest
>> najwęższy możliwy? Naprawdę nie rozumiem, co próbujesz przekazać.
>>
>> Miej litość nad głupszym kolegą i podkręć proszę jasność.
>
> To, ze przyjecie takiego zalozenia czyni ten kod (jak najbardziej zgodny
> z tym zalozeniem) _zwyczajnie bledny_ !
> Jesli nie wiesz dlaczego, to Ci zwyczajnie wspolczuję.

To potwierdza moje przypuszczenia: kolega ma po prostu trudności z
rozumieniem słowa pisanego, lub z ogólnie pojętą logiką. Nie będę zatem
ciągnął tego wątku, bo mija się to z celem.

Tymczasem mogę tylko życzyć szybkiego powrotu do zdrowia.

Mateusz

do góry

On 2019-06-22 14:47, Piotrne wrote:
> W dniu 2019-06-20 o 20:39, Janusz pisze:
>
>> Masz teoretycznie rację ale to jakiego typu zmiennej używasz zależy od języka
>
> Można jeszcze użyć typu decimal (np. w C#), który pamięta liczby
> w układzie dziesiętnym i nie ma problemów z zaokrągleniami
> liczby 0.1. Obliczenia są znacznie wolniejsze niż dla double
> (są realizowane programowo, a nie sprzętowo).

i moga dawac gorsze wyniki od obiczen na floatach
(w dodatku dajac ułudę pewnosci:).

AK

do góry

On 2019-06-23 14:57, J.F. wrote:
>> Tymczasem akcje Ursusa stoją po 0.797 zł. :)
>
> Ciekawe, czy pamietaja na float, double, czy na int w 0.1gr :-)

Nie ma znaczenie jak sa pamietane.
Wazne ja sa prezentowane (i porownywane).

AK

do góry

On 2019-06-25 22:05, Mateusz Viste wrote:
> On Tue, 25 Jun 2019 21:32:56 +0200, AK wrote:
>> On 2019-06-19 09:03, Mateusz Viste wrote:
>>>> No dobra...
>>>> Bo piszą np. potem takie z gruntu błędne konstrukcje.
>>>>
>>>> int a = cus_tak;
>>>>
>>>> if ( x & 0xFFDF )
>>>
>>> I to jest argument za tym, by nigdy nie zakładać że typ zmiennej jest
>>> najwęższy możliwy? Naprawdę nie rozumiem, co próbujesz przekazać.
>>>
>>> Miej litość nad głupszym kolegą i podkręć proszę jasność.
>>
>> To, ze przyjecie takiego zalozenia czyni ten kod (jak najbardziej zgodny
>> z tym zalozeniem) _zwyczajnie bledny_ !
>> Jesli nie wiesz dlaczego, to Ci zwyczajnie wspolczuję.
>
> To potwierdza moje przypuszczenia: kolega ma po prostu trudności z
> rozumieniem słowa pisanego, lub z ogólnie pojętą logiką. Nie będę zatem
> ciągnął tego wątku, bo mija się to z celem.

"Czyli zwuczajnie nie wiem "osochodzi"/dlaczego w/w kod jest bledny."

> Tymczasem mogę tylko życzyć szybkiego powrotu do zdrowia.

Lekarzem tez jestes rownie "dobrym" jak programista :)?

AK

do góry

On Tue, 25 Jun 2019 22:17:17 +0200, AK wrote:
> "Czyli zwuczajnie nie wiem "osochodzi"/dlaczego w/w kod jest bledny."

Miałeś wyjaśnić dlaczego zakładanie że sizeof(int) == 2 jest błędem. Ty
natomiast podajesz kod, który jest błędny właśnie dlatego, że programista
tak nie postąpił. Słowem - strzeliłeś samobója, a teraz pajacujesz.

> Lekarzem tez jestes rownie "dobrym" jak programista :)?

Nie trzeba być lekarzem aby dostrzec oczywistą patologię. Co innego aby
ją nazwać i wyleczyć - ale ja nie mam takich ambicji.

Mateusz

do góry

On 2019-06-25 22:45, Mateusz Viste wrote:
> On Tue, 25 Jun 2019 22:17:17 +0200, AK wrote:
>> "Czyli zwuczajnie nie wiem "osochodzi"/dlaczego w/w kod jest bledny."
>
> Miałeś wyjaśnić dlaczego zakładanie że sizeof(int) == 2 jest błędem. Ty
> natomiast podajesz kod, który jest błędny właśnie dlatego, że programista
> tak nie postąpił.

Otóż postąpił tu: if ( x & 0xFFDF )
Wlasnie tu przyjal, ze sizeof(int) == 2
No i opierajac sie na tym "przyjeciu" wyprodukowal klasyczny bledny kod.

> Nie trzeba być lekarzem aby dostrzec oczywistą patologię. Co innego aby
> ją nazwać i wyleczyć - ale ja nie mam takich ambicji.

Najpierw ulecz swoja "logike" i "wiedze" "programisto"

AK

do góry

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.

do góry

Dnia Tue, 25 Jun 2019 22:09:22 +0200, AK napisał(a):
> On 2019-06-23 14:57, J.F. wrote:
>>> Tymczasem akcje Ursusa stoją po 0.797 zł. :)
>>
>> Ciekawe, czy pamietaja na float, double, czy na int w 0.1gr :-)
>
> Nie ma znaczenie jak sa pamietane.
> Wazne ja sa prezentowane (i porownywane).

Ale byloby istotne w kwestii wyzszosci liczb float nad fixed czy
binary nad bcd :-)

J.

do góry

Dnia Tue, 25 Jun 2019 21:37:48 +0200, AK napisał(a):
> On 2019-06-19 11:35, J.F. wrote:
>>> 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
>
> I co z tego?
> "Problemy" z liczbami fp kompletnie nie zaleza od ich podstawy.

O tyle zaleza, ze jeden format moze miec problem z liczbami typu
31.8, drugi z 5/16, a oba z 1/3.

No i ktorych liczb uzywasz czesciej?
Od tego bedzie zalezec, ktory format lepszy :-)

J.

do góry