🚀 go-pugleaf

Dnia Mon, 12 Jun 2006 13:42:39 +0200, Adam Karpierz skrobie:
> "Aleksander Galicki" <no@no.com> wrote:

> > Mnostwo pewnie. Ale ten przyklad jest jednak dosc spektakularny.

> Tu sie zgadzam w pelni z Panem.
> Wiele uczacy.

Tu się również zgadzam, aczkolwiek błąd dla mnie nie powala na kolana.

To jest niestety integralna cecha wszystkich algorytmów, które pracują na
liczbach całkowitych o określonej wielkości - nie ma przeproś, tego typu
błędów jest wciąż w oprogramowaniu mnóstwo i przy operowaniu na mnóstwie
danych w końcu się okaże, że np. nie dodasz do zbiornika ośmiu miliardów
elementów, bo dana liczba całkowita nie ma takiej pojemności. I bujaj się.

> > I ta implementacja byla z prostym bledem, ktorego NIKT nie
> > znalalz przez 20 lat.

> Hm...
> _Nigdy_ nie zdazylo mie sie uzyc algorytmu "z ksiazki"
> bez sprawdzenia.

Słusznie. Co więcej, bezpieczne implementacje robi się zazwyczaj tak, że
określa się ramy, w jakich algorytm może pracować normalnie i operacje zostaną
wykonane poprawnie, w jakich trzeba przygotować się na korektę względem tego,
co zrobi procesor, a w jakich ten algorytm pracowac nie może i musi się
wywalić.

To nie jest moim zdaniem żaden błąd, to jest po prostu uproszczona wersja
algorytmu przewidziana do działania, na ograniczonym zakresie liczb. Jeśli
komuś się wydaje, że poprawka tego typu:

int mid = ((unsigned)left + (unsigned)right)/2;

czy:

int mid = ((long)left + (long)right)/2;

załatwi sprawę, to musi się jeszcze trochę nad sobą zastanowić.

Nie, w samym algorytmie błędu nie będzie. Będzie "trochę gdzie indziej". Jeśli
piszemy algorytmy na liczbach całkowitych o określonej pojemności, to algorytm
musi mieć określone ramy, w ktrych działa dobrze. Jak nie, to stosujemy
bignumy.

> Troche odbiegne od tematu:
> Powiem szczerze ze nigdy pozniej nie spotkalem (no z jednym
> wyjatkiem) ksiazki ktora by w taki profesjonalny sposob podchodzila
> do sprawy jak w/w.

Jeśli chodzi o Bentley'a, to się również zgadzam ;)

> > Nastepnie dobry programista (J Bloch) zaimplementowal ten algorytm na

> dobry programista nie implikuje bezbledny programista

Myślę wręcz, że "bezbłędny programista" to oksymoron ;)

> "We must program carefully, defensively, and remain ever vigilant."

> A Tu sie z w/w i z Panem zgadzam w pelni.

Też się zgadzam, ale to stwierdzenie jest zgoła banalne - praca inżyniera nie
polega na przenoszeniu rozwiązań z jednego miejsca w drugie, tylko na
stosowaniu poprawnych rozwiązań

> Niestety nie da sie ukryc ze wsrod "mlodziezy" jest to coraz rzadziej
> spotykana metoda. Ide, debuggery i inne takie jej nie sprzyjaja.
> Moze to ze na Odrze czekalo sie na kompilacje np tydzien
> (i dlatego program byl maksymalnei wycyzelowany) nie bylo takie zle :) ?

Cóż, tendencja do ułatwiania sobie życia temu nie sprzyja - ostatnio jak
trzeba było zbyt dużo czasu czekac na samo odpalenie kodu na docelowej
maszynie, co wydłużało cykl poprawki-kompilacja-weryfikacja, zrobiło się
host-testy.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"