Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
dyskusyjnych:k7c774$3tq$...@n...task.gda.pl...
> Jestes w stanie podac konkretne nazwy i namiary ? (tylko daruj sobie
> jakies

Jestem w stanie.

do góry

Użytkownik "slawek" <s...@h...pl> napisał:
>
> Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
> dyskusyjnych:k7buma$f2q$...@n...task.gda.pl...
>> Czy _cokolwiek_ gwaranutuje ci dokladne obliczenia w/g nietrywialnych wzorow
>
> Gwarantować nie gwarantuje, ale na pewno ogranicza możliwość poważnej wpadki

Nie. Nie ogranicza.
Przesuwa w inne rejony (np. ta 1/3dla decimala).
System (podstawa) obliczen nie ma tu zadnego znaczenia.
Problem rozwiazalaby nieograniczona mantysa, lecz taka nie jest mozliwa
wiec fp beda _zawsze_ niedokladneczy beda dwojkowe czy 17stkowe.
Oczywiscie w przypadku gdy mamy pewnosc ze "najgorszym" dzialaniem
bedzie dzielenie, rozwiazaniem jest typ rational (Poczytaj sobie np.
o Pythonowym Fraction), ale taki zalozenie ciezko dotrzymac nawet w
trywialnej bankowosci/finansach.
Bzdurzysz i brniesz wiec w dalszym ciagu.

> niezatrudnianie przy projekcie kogokolwiek, kto pisze "gwaranutuje", "jeszze" i
"niala"
>
> I nie chodzi o jakąś bezbłędność i ogólnie trzymanie poziomu przynajmniej takiego
jak na maturze z
> PRL. Ale o brak umiejętności zainstalowania automatycznej korekty pisowni.

Zalosny jestes "hrabio" ze Zglobnia.

> TC 1.0 nie potrafiło dzielić - przestawiało dzielną i dzielnik.

Tu chodzilo mi o TC++1.0 .

Ale fakt. co do TC1.0. Nawet TC2.0 mialo jeszcze _mase_ bledow (najlepsze bylo TC1.5)
Na tyle powaznych ze zmuszony bylam napisac cala bibioteke standowa
do TC2.0 "from scratch" w assemblerze.
Co nie znaczy ze po takich "doróbkach" nie dalo sie go uzywac. Dalo (bo "musialo").
Tylko ze TC/BC poznalem doglebnie w pol roku bardziej niz taki gigant jak fir przez
cale zycie.

> Zdumiewające, że BC5 miało ten sam błąd raz jeszcze.

Co mi sie zdaje ze zwyczajnie stulasz z tym bledem dzielenia.
Nawet spawdzone bc++4.52 mialo dosc powazne bledy, ale nie takie.
Konkrety prosze.

>> Jak widac Asseco nie upadlo jakos :) i defBank tez z tego powodu sie nie posypal.
>
> Kwestia czasu.

No.. Juz minelo ok 20 lat, a dzis Asseco to wlasciwie koncern miedzynarodowy
Jak dlugo jeszcze mam czekac na ta wieszczona przez ciebie katastrofe z powodu
stosowania fp ? :)
Do emerytury zdaze ? :)
Zwlaszcza, ze mialem w zleceniach klauzule (coz.. takie czasy byly...) ze programista
odpowiada
bezposrednio materialnie i cywilnie wzgledem banku(ow) za bledy wynikle z jego ew.
nieprofesjonalizmu :) ?

>> Gdy sie to umie i czuje to mozna ich uzywac nawet jako dokladnych integers /80bits
>> to zawsze wiecej niz wtedy 16/32/ a dzis 64 :)
>
> Można nawet zupę szczawiową jeść pałeczkami. Tylko po co? Po co?

Po to glupi nadety palancie aby w dobie 16 bitow mozna bylo miec w bazie
danych indeksowane pole typu "int" a (wiec typu ID) "nieco" wieksze od
64 6xx czy nawet 2 000 000.
Domyslasz sie po co ?

>> gdzie juz w pierwszym algorytmie (simplex) stalo jak byk cos w rodzaju:
>> if abs(a-b) <= EPS then return
>> i nie byl zadnego magicznego DBL_EPSILONA
>
> Nauczyć ciebie rozróżniania Algolu od C ? Jest to wykonalne?

Mnie chcesz C uczyc ?
http://karpierz.net/CV/certC.jpg
Juz calkiem ci odwala "hrabio" z koziej Wolki ?
Akurat w przypadku tego certifikatu zmiescilem sie w topowych 4%
z wszytskich dotychczas startujacych :).
PS: Pociesze cie. Dla C++ bylo juz gorzej /tylko w 28% topu/ :)
PS1: DBL_EPSILON nie ma nic wspolnego z jezykiem/kompilatorem.
To cecha koprocesora. Dla Algolu na PC bedzie taka sama
jak dla C.

AK

do góry

Użytkownik "slawek" <s...@h...pl> napisał:

> Ten wątek jest jak najbardziej o programowaniu, a mianowicie o odpowiedzialnym
używaniu liczb
> zmiennoprzecinkowych,

Ty nie masz _bladego pojecia_ o odpowiedzialnym i profesjonalnym uzywaniu liczb fp.

AK

do góry

Użytkownik "slawek" <s...@h...pl> napisał:

> Jestem w stanie.

Wątpie.

AK

do góry

Uzytkownik "kenobi" <p...@g...com> napisal:
> wprowadzic dwa rodzaje operatorow dzielenia stratnego i bezstratnego itd

No baardzo ciekawe. :)) Heh
W jaki sposob chcesz uzyska programistyczny dresie to "bezstratne" dzielenie ?
Bo mnie sie wydaje, ze jest tylko jeden sposob: przez zaniechanie dzielenia

AK

do góry

Użytkownik "kenobi" <p...@g...com> napisał w wiadomości grup
dyskusyjnych:48af486e-7684-4e70-b230-c4d17d9219b7@go
oglegroups.com...

> Odnosnie floaciakow i porownywania (taki watek

Jest np. coś takiego http://www.lce.hut.fi/teaching/S-114.1100/lect_1.pdf

W tzw. "świetle najnowszych badań, które zostały zaprezentowane na
pl.comp.programming" - to zwyczajnie fińskie "Centre of Excellence in
Computational Complex Systems Research" uczy dzieciaków głupot (i to za 5
pkt. bolońskich).

> w znanym przykladzie z "f=0.1;" (tj for(float f = 0.0; f!=1.0; f+=0.1);
> problemem jest raczej po prostu samo "f=0.1;" (a nie
> porównanie f!=1.0) IMO na "f=0.1;" powinien raczej
> lecieć nawet bład kompilacji

Dokładnie taki sam problem jak z for(int i = 1; i != 6 ; i+=2) ;

do góry

Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
dyskusyjnych:k7ccor$ged$...@n...task.gda.pl...
> Co mi sie zdaje ze zwyczajnie stulasz z tym bledem dzielenia.

Wydaje ci się. Raz jeszcze był ten błąd: ale tylko gdy dzieliło się unsigned
long int przez singned short int (lub coś w ten deseń).

> No.. Juz minelo ok 20 lat, a dzis Asseco to wlasciwie koncern
> miedzynarodowy

Gdzie ja czytałem, że właśnie położyło przetarg?

> Domyslasz sie po co ?

Po to aby niedouczony programista nie musiał używać uint64_t ?

> Mnie chcesz C uczyc ?

Widać trzeba, skoro chcesz szukać float.h w Algolu.

do góry

Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
dyskusyjnych:k7ccvc$guq$...@n...task.gda.pl...
> Wątpie.

Twój problem.

do góry

Uzytkownik "AK" <n...@n...com> napisal w wiadomosci grup
dyskusyjnych:k7cdcl$hqj$...@n...task.gda.pl...
> Bo mnie sie wydaje, ze jest tylko jeden sposob: przez zaniechanie
> dzielenia

Wydaje ci sie.

do góry

Dnia 01.11.2012 kenobi <p...@g...com> napisał/a:
[...]
> eogole z tego co kojarze to kompilatory
> zdaje sie byc moze bez problmu obslugują
> tzw typ long double
>
> long double x = 1.0;
>
> (wieadomo 80 bit) mimo ze sie tego w kodach rzadko uzywa mozliwe ze wiekszosc
kompilatorow to po prostu normalnie obslugują
>
> ktos wie jak to z tym jest?

Zależy to nie tylko od samego kompilatora, ale tez od maszyny na jaką
program jest kompilowany. Nie wiem jak jest z Microsoftowym VC (w
Express Edition typ double i long double to domyślnie to samo, czy
jest jakiś przełącznik, to nie wiem) ale GCC kompilując na procesor
x86 rozróżnia double (64-bitowy) i long double (chyba 80-bitowy, choć
zmienne mają po 96 bitów, ale nie badałem tego dokładnie) obydwa
liczone przez FPU. Ma też specjalny typ __float128 (128-bitowy)
liczony zasadniczo programowo (oczywiście używając FPU do
pomocy). Natomiast ten sam GCC kompilując na procesor SPARC nie robi
rozróżnienia pomiędzy long double i __float128, i obydwa typy liczy
sprzętowo (FPU w SPARC-u ma możliwość połączenia swoich 32 64-bitowych
rejestrów w pary tworząc 16 rejestrów 128-bitowych, więc autorzy GCC
doszli do wniosku, że nie ma sensu implementować softwareowo
80-bitowej arytmetyki, która byłaby wolniejsza od 128-bitowej a
jedynym zyskiem byłaby oszczędność pamięci). W Intelowskim icc była
jakaś flaga do przełączania czy long double ma być taki jak double czy
większy, ale nie używałem już icc kilka lat, więc nie wiem jak to jest
teraz.

do góry