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