'Drobne" błędy

Głośna ostatnio "afera Pentium" została już opisana na niemal wszelkie możliwe sposoby. Przy okazji podano wiele innych przykładów omylności systemów informatycznych.

Głośna ostatnio "afera Pentium" została już opisana na niemal wszelkie możliwe sposoby. Przy okazji podano wiele innych przykładów omylności systemów informatycznych.

Wniosek ma być taki, że mylić może się nie tylko człowiek (jako twórca wadliwego programu), lecz za błąd może być również odpowiedzialny komputer, źle realizujący dobry program. Wydaje mi się jednak, że większość przykładów omylności zarówno ludzkiej, jak i "maszynowej" pokazuje, jak w niepamięć poszła analiza numeryczna i jak niski poziom prezentuje ciągle inżynieria oprogramowania.

Każdy konstruktor mostu lub samolotu, wie że musi przestrzegać określonej metodologii, jeśli chce uzyskać produkt, który się nie zawali lub nie rozbije podczas lądowania. Metody pracy "klasycznych" inżynierów narzucone są często przez koszty procesu projektowego i później produkcyjnego, wymagających określonej infrastruktury, technologii oraz materiału. Inaczej jest podczas tworzenia oprogramowania. Powszechnie jeszcze uważa się, że do napisania programu praktycznie niczego nie potrzeba. Wystarczy kartka i ołówek. Niektórzy nawet od razu zasiadają do komputera i wpisują kod. Nie ma całej kosztownej infrastruktury, która wymuszałaby określoną metodykę pracy.

Stosując takie podejście można uzyskać bardzo dobry produkt. Może jednak również powstać program wadliwy, obarczony błędem do uniknięcia przy zastosowaniu odpowiedniego podejścia. Kiedyś podczas wykładów w pewnym amerykańskim uniwersytecie chciałem zastąpić używany tam kompilator bardzo dobrym produktem polskim. Podczas pierwszych zajęć zadałem studentom proste ćwiczenie - napisanie programu tablicującego różne funkcje standardowe. Wyniki były katastrofą - wartość sinusa potrafiła osiągać nawet 5. Szybko ustaliłem przyczynę błędów. Autorzy polskiego kompilatora dla zaoszczędzenia sobie pracy wykorzystali gotową bibliotekę funkcji standardowych z innego produktu, nie sprawdzając czy po przeniesieniu będzie poprawnie funkcjonować. Usunięcie tej usterki nie było niczym skomplikowanym, poza tym polski produkt był naprawdę doskonały. Niestety, przez proste zaniedbanie stracił wszelkie szanse - nikogo już nie mogłem do niego zachęcić. Innym zagadnieniem jest zaniedbywanie analizy numerycznej. Jak wiadomo, komputery operują na skończonej liczbie bitów. Tak więc każda operacja i wszystkie liczby są reprezentowane przez skończony ciąg zer i jedynek. Oznacza to, że każda liczba całkowita mieścić się musi w pewnym zakresie, a liczby ułamkowe mogą osiągać tylko pewną maksymalną dokładność. Stwierdzenia te są najprawdopodobniej oczywiste dla osób zawodowo związanych z komputerami. Mimo to proponuję przyjrzenie się pewnemu przykładowi. Poniżej przedstawiam dwa układy równań z dwiema niewiadomymi:

2x + 6y = 8

2x + 6.00001y = 8.00001

oraz

2x+ 6y = 8

2x + 5.99999y= 8.00002

Jak widać, oba zestawy różnią się między sobą bardzo niewiele. Wydawałoby się więc, że rozwiązania obu równań również powinny być bardzo do siebie zbliżone. Nie chcę odbierać Czytelnikowi przyjemności samodzielnego rozwiązania tego problemu, dlatego prawidłowe rozwiązania umieściłem na końcu felietonu. Proszę zwrócić uwagę, że liczby w powyższym przykładzie różniły się od siebie dopiero na piątym miejscu po przecinku. Jak pamiętamy, w debacie nad Pentium argumentowano, że tego typu niedokładności nie mają żadnego znaczenia. Tak prosty przykład pokazuje, jak niewiele zastanawiamy się nad analizą numeryczną. Nie myślimy, jak w stosowanych algorytmach wartości liczbowe są zastępowane liczbami przybliżonymi, nie uwzględniamy, że dane doświadczalne są zawsze obarczone błędem. Zapominamy o wytwarzanych w czasie obliczeń błędach zaokrągleń, zapominamy o przybliżonych algorytmach. Niewielkie, wręcz "zaniedbywalne" różnice mogą w pewnych przypadkach prowadzić do rozwiązań dalekich od oczekiwanych - mamy wówczas do czynienia z zadaniami źle uwarunkowanymi, którym i najlepszy algorytm nic nie pomoże. Dla osób wykorzystujących komputer do gier komputerowych takie pomyłki mogą mieć niewielkie znaczenie. Jeśli jednak zapomina o nich twórca programu sterującego lotem samolotu, to wolałbym nie wsiadać na pokład.

Rozwiązanie równań:

Równanie I: x=1; y=1

Równanie II: x=10; y=-2

Profesor dr hab. Jan Madey jest dyrektorem Instytutu Informatyki Uniwersytetu Warszawskiego

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200