On 2019-06-13 23:22, bartekltg wrote:
[...]
> BTW, long int to raz 32, raz 64 bity. A teoretycznie może mieć i inną wartość;-)
A czasami zwykły int to raz 16, a raz 32 bity. :-) W zależności od
ustawień kompilatora - vide MCU z rodziny H8/300H, H8S i pokrewne.

do góry

On Thu, 13 Jun 2019 14:22:06 -0700, bartekltg wrote:
> 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.
>
>> 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...
>
> Co najwyżęj, jak obracasz walutą. Standard to chyba 1/10000 jednostki
> (złotówki, dolara...).
>
> BTW, long int to raz 32, raz 64 bity. A teoretycznie może mieć i inną
> wartość;-)

Prawdziwi programiści zakładają, że typ danych jest najwęższy możliwy:
int=16, long=32, long long=64. A jeśli chcą czegoś konkretnego to znają
stdint.h i potrafią korzystać z uint32_t i jemu podobnych.

Mateusz

do góry

On 2019-06-12 14:44, J.F. wrote:
> Użytkownik "Pszemol"  napisał w wiadomości grup

> To nie jest problem VB, to jest problem przyjetego formatu liczb
> rzeczywistych.

I tam. Nieprawda. W _kazdym_ systemie/formacie FP moze sie zdarzyc.

> Albo problem programisty :-)

_Wylacznie_ problem programisty.

> Po prostu nie da sie zapisac 32.8 dokladnie.
> Programista ma o tym wiedziec i sie zabezpieczyc :-)

Prawda!

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

> Akurat .net ma dodatkowe formaty (Decimal), w ktorych powinno to dzialac.
> Tylko trzeba ie
> Ale i tak bym dorzucil zabezpieczenie.

Racja! Sam Decimal tak naprawde przed niczym sam z siebie nie chroni.

> Problem promieniuje na bazy danych, gdzie mamy duzo kwot, a te grosze
> tez nie sa dokladne :-)

Raaacja ! :)

AK

do góry

On 2019-06-12 17:27, J.F. wrote:

> Kto nie uczyl sie Fortranu, ten nie zna zycia :-)

O przepraszam ! Ja sie uczylem Agolu/Simuli!

PS: No dobra.. Fortranu też ;)

AK

do góry

On 2019-06-12 16:54, Cezary Grądys wrote:
> W dniu 12.06.2019 o 14:29, Mateusz Viste pisze:
>
>>
>> Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
>>
>> Obowiązkowa lektura na wieczór:
>> http://perso.ens-lyon.fr/jean-michel.muller/goldberg
.pdf
>>
>
> Nie ma co przesadzać, liczby zmiennoprzecinkowe po to powstały, żeby je
> używać. Trzeba tylko porównywać je zakładając pewną dopuszczalną
> tolerancję.

No dooobra.
Zamieszcze tu po raz 473 w ciagu 20 lat podstawową formułkę
(Ba! KANON!), bo przy takiej wiedzy "mlodego pokolenia" znow
zaczną nam przychodzic ponaglenia o pilną zapłatę 0.00PLN.

a == b -> fabs(a - b) <= EPS
a != b -> fabs(a - b) > EPS
a < b -> (a - b) < -EPS
a > b -> (a - b) > EPS
a <= b -> (a - b) <= EPS
a >= b -> (a - b) >= -EPS

PS: Oczywiscie EPS moze miec rozna nature i wartosci zaleznie np.
od domeny (numeryka, finanse itp). Np. Moze byc bezwzgledne, ale
czesto bywa wzgledne, a w numeryce to juz w ogole...
Np. w optymalizacji moze byc dynamiczne (np zalezne nie tylko
od wartosci ale i innych cech funkcji, np gradientu) i sztuka
sama w sobie jest je dobierac/szacowac np w slabo zbieznych algorytmach
czy gdy np. funcja jest baaardzo stroma. No ale to juz zupelnie inna
"para kaloszy".

PS0: Oczywiscie w niektorych "higienicznych" przypadkach (np. szukanie
wartosci maksymalnej) dopuszczalne jest zwykłę >, ale to nie
łamie/przeczy w/w regułom.

AK

do góry

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).
2. przy dzisiejszych koprocesorach ? Na pewno warto ?
/Kiedys zdecydowanie tak, wiec absolutnie podejscia nie potępiam/.

AK

do góry

On 2019-06-13 23:22, bartekltg wrote:

>>> Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
>
> Pieprzenie. No, czyba, że programowanie = frontend.

100% zgody :) Uzyte slowo tez wlasciwe/adekwatne ;)

AK

do góry

On 2019-06-13 23:25, bartekltg wrote:
>> W ogolności
>> fl(a+b) = (fl(a)+fl(b))(1+eps), gdize ten epsylon to dokłądność
>> reprezentacji.
>
> Lepiej by było, jakbym napisał, że eps jest rzędu wielkośći reprezentacji.

O tak. To bardziej adekwatne.

AK

do góry

On 2019-06-14 08:19, Mateusz Viste wrote:

> Prawdziwi programiści zakładają, że typ danych jest najwęższy możliwy:
> int=16, long=32, long long=64.

Niestety to duzy blad :(

AK

do góry

> Musialbym sobie przypomniec ... ale przy okazji Assemblera raczej nikt
> nie poruszal takiego watku.

Pierwsze publikacje o Asemblerze x86 pomijały 386 i koprocesor.
W takiej "Asembler nie tylko dla orłów" Grzegorza Michałka
(Intersoftland 1997) jest opisany 386 (i 486) z koprocesorem. I co
prawda nie rozwodzi się tam nad dokładnością obliczeń, ale... Podaje
jako jeden z możliwych błędów/wyjątków: "Utrata precyzji"/"Błąd
precyzji" - bit 6 rejestru stanu koprocesora.

> Przy C predzej, ale to gdzies na pograniczu.

Tak czy owak nie powinno się pomijać kilku słów komentarza, podczas
omawiania typów zmiennoprzecinkowych, na temat potencjalnych problemów
przy ich stosowaniu.

do góry