Sądząc po powtarzających się odpowiedziach zdecydowania większośc z
Państwa korzystała z gotowego opracowania pytań z zeszłego roku.
Kilkukrotnie ostrzegałem, że zawiera ono wiele błędów i braków. W
szczególności, nie uwzględnia ono elementów omówionych na wykładzie,
ale nie zapisanych na slajdach. Co więcej, chyba nikt nie zadał sobie
trudu by sprawdzić, czy treść opracowania zgadza się z aktualną
treścią wykładu - były zmiany!!!
Kilka uwag do pytań
---
Pytanie dotyczyace założeń KOMUNIKACJI z użyciem USB
Większośc osób pisała różne rzeczy, ale nic na temat.
W pytaniu chodziło przede wszystkim o to, ze kontroler rozsyła tokeny, a
urządzenie podłaczone do magistrali musi czekać, aż taki token bedzie
przeznaczony dla niego. Dopiero wtedy może sie ono "odezwać". Dobrze też
było wspomnieć o kanałach wirtualnych.
W częsci pytania dot. rezerwacji pasma w USB wiele odpowiedzi sprowadzalo sie do
tego, ze "rezerwacja pasma polega na zarezerwowaniu pasma" (czyli nie
wyjaśniały nic). Tymczasem, należało napisać, że transmisja po USB opiera
sie na zapytaniach wysyłanych przez kontorler (czyli tokenach), a rezerwacja
pasma polega na tym, ze tokeny dla wybranego urzadzenia sa przesylane z
okreslone czestotliwoscia i im wieksze ma byc pasmo tym ta
czestotliwosc jest wieksza.
W danej chwili do medium transmisji moze byc dolaczony tylko jeden nadajnik.
Rezerwacja pasma gwarantuje, ze okresow w ktorym dane urzadzenie bedzie
podlaczone, bedzie odpowiednio duzo. Czas, przez jaki urzadzenie ma dostep
do magistrali przeklada sie na ilosc danych, jakie moze wyslac, a to z kolei
okresla sie mianem pasma transmisji.
- w pytaniach dotyczacych instrukcji warunkowych i petli w Matlabie należało
podac składnię tych instrukcji i (najlepiej) przykład. Większośc osób
próbowało to dać w odpowiedzi, ale bardzo czesto błednie (zwłaszcza
dotyczyło to switch)
Nagmiennie mylono pojęcia instrukcja warunkowa, funkcja i pętla.
W opisie instrukcji "if" należało podac w jaki sposób opisuje sie i definiuje
warunki logiczne oraz łaczy je ze sobą(wystarczyło podac jakis przykład)
Z kolei przy pętlach brakowało bardzo często opisu, kiedy sie je stosuje
/ kiedy lepiej uzyć for a kiedy while.
- w pytaniu o model kaskadowy, sam opis etapów w większości był OK, ale często
zbyt krótki. Do każdego należało napiasać coś wiecej niż 3 słowa.
Natomiast mało kto napisał o wadach i zaletach tego modelu oraz czy jest obecnie
stosowany i (mimo, ze nie jest stosowany) dlaczego jest taki wazny
- w pytaniu o transmisję z potwierdzeniem
W niektórych pracach zabrakło brak schematu, a w niemal wszystkich
dopisku, ze ten
schemat to tylko ogólne przedstawienie ideii, natomiast jej konkretne realizacje
zaleza od protokołu wymiany danych - moga to byc jawnie połączone linie (czyli
tak jak na schemacie) ale także komunikaty kontrolne, pakiety
sterujące (np. w SATA), itp.
Parę osób w opisie wprawdzie zawarło bardzo dokładnie w jakiej
kolejności ustawiane są sygnały potwierdzeń, ale... zapomniało napisać
w którym momencie jest wykonywany zapis i odczyt danych
- pytanie o zapis stąło i zmiennoprzecinkowy
wiekosc odpowiedzi byla tylko czesciowo poprawna. Zwykle skupiali sie panstwo na
mało istotnych ciekawostkach (np. kwestia porównań) i przypadkach
nietypowych zamist tego co istotne.
Jako najwieksza, a czasem jedyna zalete zapisu zmiennoprzecinkowego
podawano, że łatwo
zmienic znak liczby. Czy to na prawde jedyna zaleta? Po co wiec
stosowac taki skomplikowany
zapis dla tej jednej, jedynej zalety? Pomiajano najistotnisjesza ceche zapisu
zmiennoprzecinkowego polegającą na tym, ze zapisuje on pewna stałą
liczbę znaczących cyfr
liczby (czyli zapisuje tylko to co jest w liczbe "najwazniejsze"). Np.
liczbe 1000200003
zapisze jako 1000200000, ale 0.1000200003 zapisze jako 0.1000200000,
a 1230000.0020000234 jako 1230000.00200000000
Kolejne ciekawe stwierdzenie, to to, że nie mozna zapisac liczby 0.
Oczywistym jest, ze
mozna ja zapisac, i to nawet jako +0 i -0. Natomiast w wykładzie pada
stwierdzenie, ze nie można jej zapisac stosujac wyłacznie podstawowe
zasady konwersji liczby na postac zminnoprzecinkowa. Trzeba zastosowac
specjalna kombinacje mantysy i cechy.
Parę osob pisalo, ze mantysa to część ułamkowa, a cecha - całkowita.
Tymczasem cecha to
nie częśc całkowita a wykładnik mnoznika mantysy. Tak na marginesie,
wzór na skladnieki
liczby zmiennoprzecinkowej należało podać!
Nagminnie pisano, że w zapisie zmiennoprzecinkowym liczbę bitów na
częśc ułamkową i całkowitą można sobie dopasować w zależości od
potrzeb - NIE, nie można. To jest zupełnie inny sposób zapisu liczby i
nie mozna tu mówić o tym, że jakaś część bitów koduje część całkowitą
a inne ułamkową -> ponownie kłania się kwetsia cechy i mantysy.
Jako jeden z problemów podawano, że nie mozna zapisac liczby 3/10. Czy
tylko tej jednej? A 1/10, albo 3/100?
Tu chodzi o ogólna właściwość, że nie każdy ułamek dziesiętny da sie
zapisac dokładnie co wynika z innej podstawy systemu obliczeń i
ograniczonej liczby bitów.
Ostatnie dziwne stwierdzenie dotyczyło porównań - problem porównan
występuje nie zawsze, ale tylko wtedy, gdy dwie porównywane liczby sa
zapisane w roznych standardach, np. jako float i double, albo jako
zmienno i stałoprzecinkowa. W kazdym razie nie jest to najistotniejszy
problem z zapisem liczb ułamkowych w komputerze
- w pytaniu o przetwarzaine potokowe wiele osób chyba nie zrozumiało
ze w tego rodzaju przetwarzaniu chodzi o podział JEDNEJ instrukcji na
pewne etapy. Kolejne instrukcje mogą byc dzieki temu rozpoczynane
zanim zakończą sie poprzednie.
Wiele osób twierdziło, że jakoby taki pojedynczy blok / etap
instrukcji moze sie zapętlić... n
a prawdę nie mam pojęcia jak by to miało wyglądać....
- w pytaniu o testy oprogramowani. Szczególne rażące było
stwierdzenie, ze małe blędy sa dopuszczalne.
Jest tak TYLKO w pewnych, uzasadnionych przypadkach, gdy wiemy
dlaczego błędy sie pojawiają i
co znaczą. W wiekoszci przypadkow rozbieznosci nie sa dopuszczalne i
nie moga sie Panstwo
przed odbiorcą programu tłumaczyć, ze wszystko w programie jest dobrze
bo przeciez bledy sa małe.
Czy ktoś z Państwa chciał by lecieć samolotem w którym drzwi się
"trochę" nie domykają, bo małe błedy są dopuszczalne?
W częsci dotyczącej zbiorów danych testowych Wiele osób napisało, że
testuje sie dla wartości losowych oraz z granic przedziałow. Otóż
wartości losowe wcale nie są dobre, ponieważ mogą nie miec sensu (np.
przy złożonym algorytmie, np. obliczen wytrzymałościowych konstrukcji
- dane wejściowe muszą opisywac konstrukcję, a więc nie moga być
przypadkowe).
Zgadza sie, ze dane losowe sie czasem stosuje, ale nie zawsze i nie
wszedzie. Co do drugiego stwierdzenia, program nalezy testować dla
danych poprawnych (wyniki muszą być poprawe dla poprawnych danych),
niepoprawnych (dla danych blednych program powinien zachowywac sie
"sesnownie", np. podajac komunikaty o bledzie danych) ORAZ dla
wartosci z granic przedziałów (poniewaz tam bardzo często występują
błędy, które bez tego typu testów łatwo przeoczyć)
- w pytaniu o protokól HTTP niemal wszędzie brakowało najwazniejszych
informacji o nim (np. że jest bezstanowy, i co to znaczy).
- w pytaniu o enkapsulacje nikt (może poza 2 czy 3-ma osobami) nie
napisał jak to działa. (slajd 72 z prezentacji 10). A sama
enkapsulacja jest konieczna po to, żeby dane wysłane przez protokół
wyższej warstwy (np. IP) mogły być przesłane do odbiorcy przez
protokoły niższych warstw (np. Ethernet). One nie interpretują tych
danych ani ich nie "rozumieją" - po prstu jest to jakiś ciąg bitów,
który trzeba przesłać. A żeby go przesłać, trzeba go "zapakować" w
ramkę. Po drugiej stronie odbiorca "rozpakowuje" taką ramkę i to co z
niej "wyciągną" podaje wyżej. I dopiero funkcje realizujace obsługę
tego wyższego protokołu analizują dane, które dostały. Ponadto,
enkapsulacja jest konieczna ponieważ rozmiary ramek poszczególnych
protokołów mają różne długości i np. wspominanego już pakietu IP nie
da sie wysłać w jednym pakiecie Ethernet - trzeba go podzielić na
kilka ramek.
- w pytaniu o przerwania było bardzo dużo błędów.
Najczęstszy to stweirdzenie, że jeden program przerywa drugi. Nie,
przerwania to sprawa sprzętowa i są zgłaszane przez urządzenia. To
urządzenie daje procesorowi (zwykle za pośrednictwem kontrolera
przerwań) sygnał, że ma jakąś ważną informację. Procesor, jeśli
zdecyduje się obsłużyć przerwanie, wstrzymuje aktualny program i
wykonuje tzw. procedurę obsługi przerwania. Gdy ją skończy - wraca do
zatrzymanego wcześniej programu.