141310.ocena(4.0) ; brak kilku ważnych odcięć; w odległości Hamminga należało zliczać jedynki a nie długość 141327.ocena(2.0) ; za dużo błędów; każdemu predykatowi można zarzucić jakiś błąd 141183.ocena(2.0) ; elementarne wręcz błędy; tylko zliczanie jedynek jest ok; reszta kuleje 141321.ocena(5.0-) ; niepotrzebne ciągłe odwracanie bitów (należało pracować na odwróconych!); ; nie zawsze działający warunek stopu dla min. odl. Hamminga 141204.ocena(4.0) ; niewłaściwy sposób odwracania ciągów bitów; odległość Hamminga liczona od najbardziej znaczących; ; błąd w liczeniu minimum z odl. Hamminga 141200.ocena(2.0) ; za duża liczba błędów w stosunku do tego co zostało zrobione 141203.ocena(5.0) ; bardzo dobrze 141222.ocena(4.0) ; błędy w predykacie wyznaczania wszystkich odl. Hamminga; nie dokończony predykat główny 141326.ocena(3.5) ; okropnie przekombinowana odl. Hamminga i do tego zawsze zaniża wyniki o 1; ; niepoprawne szukanie min. odl. Hamminga 141181.ocena(2.0) ; podstawowe wręcz błędy; w zasadzie tylko konwersja jest ok; reszta niestety nie 141187.ocena(4.0) ; brak predykatu głównego i wyszukiwania min. z kluczem 141335.ocena(4.5) ; w odległości Hamminga należało zliczać jedynki a nie długość 141211.ocena(4.0) ; błąd w konwersji do bin; niepoprawne zakończenie szukania min. odl. Hamminga; błędny wynik końcowy 142179.ocena(2.0) ; tylko konwersja na bin poprawna, choć jej użycie już nie; podobnie jest ze złym ; zastosowaniem sortowania; wszystko to za mało na zaliczenie 141312.ocena(2.0) ; elementarne wręcz błędy logiczne w rekurencji; takie predykaty jak konwersja na bin czy sumowanie ; nic tutaj nie pomogą, kiedy gdzie indziej mamy takie potknięcia :-( 141303.ocena(2.0) ; mnóstwo błędów i braków; jest tylko konwersja na bin bez zarzutów; za mało na zaliczenie Drodzy Państwo, Pomimo faktu, iż wręczyłem Wam treść zadania z przykładami stwierdzam z niemałym zdziwieniem, że część osób nie zrozumiała zadania i pojęcia odległości Hamminga. Proszę zauważyć, że kiedy dokonujemy konwersji liczby do postaci binarnej to istotna jest KOLEJNOŚĆ bitów w tej reprezentacji, gdyż zliczanie różnych bitów między dwoma ciągami/listami binarnymi musimy prowadzić od bitów mniej znaczących. Zatem, dla przykładu, jeśli mamy dwie liczby: 1 oraz 25, to ich postaci binarne odpowiednio będą listami: dla 1 to [1] dla 25 to [1,1,0,0,1] Teraz, wyliczenie odległości Hamminga takich dwóch ciągów o różnej długości wymaga ich wirtualnego "wyrównania" zerami wiodącymi (oczywiście tego krótszego!), czyli otrzymamy wtedy listy [0,0,0,0,1] dla 1 [1,1,0,0,1] dla 25 a odległość ta wyniesie wtedy 2. Oczywiście nie ma konieczności faktycznego dodawania zer wiodących. Należy po prostu pamiętać, że kiedy - idąc od prawej strony, czyli bitów mniej znaczących - jedna lista się skończy, to w tej pozostałej (dłuższej), należy zliczyć JEDYNKI. W naszym przykładzie zatem będzie tak, że trzeba policzyć jedynki w liście [1,1,0,0], która została po porównaniu pierwszych bitów w obydwu liczbach. Bardzo wiele osób popełniało ten błąd, iż wyliczało DŁUGOŚĆ tego fragmentu, co jest niepoprawne, bo choćby w naszym przykładzie widać, iż długość ta wynosi 4, ale przecież różne są tylko 2 bity! Proszę też zwrócić uwagę, że ten dłuższy fragment wcale nie musi mieć długości równej jeden, bo może ona być całkowicie dowolna (zależy przecież od wartości liczby wejściowej). Taki błąd również pojawił się w kilku pracach. Ważne jest również to, że zaczynamy cały proces porównywanie bitów od prawej strony, czyli od mniej znaczących. Całkiem spora liczba osób robiła konwersję z append'em postaci: bin(0,[]):- !. bin(N,W):- N1 is div(N,2), H is mod(N,2), bin(N1,W1), append(W1,[H],W). żeby mieć bity na liście we właściwej kolejności (te mniej znaczące z tyłu), ale potem kompletnie ignorowali ten fakt i kiedy dochodziło do wyliczenia odległości Hamminga, zaczynali od głowy takiej listy binarnej (a tam przecież są bity najbardziej znaczące!) zamiast wcześniej listę odwrócić. Nie muszę chyba nikogo przekonywać, że wyniki uzyskiwane przy takich obliczeniach całkowicie odbiegały od poprawnych rezultatów. Poza tym wiedząc, moich mili Państwo, iż w języku Prolog rekurencyjne przetwarzanie list przebiega od lewej do prawej strony listy, nie warto upierać się przy poprawnej kolejności bitów podczas konwersji. Lepiej zastosować najprostszą możliwą wersję konwersji (bez append, ale z uzgodnieniem): bin(0,[]):- !. bin(N,[H|W]):- N1 is div(N,2), H is mod(N,2), bin(N1,W). gdzie bity najmniej znaczące będą rozpoczynać listę. Potem nie trzeba bowiem przejmować się prawidłową kolejnością bitów przy obliczaniu odległości Hamminga i można uniknąć konieczności odwracania list zerojedynkowych, która nie jest wcale potrzebna i w istocie tylko komplikuje rozwiązanie. Trudno mi wyjaśnić skąd wzięła się ta niefrasobliwość w Państwa programach, bo kwestia reprezentacji binarnej, jej porządku oraz rozróżniania pozycji mniej i bardziej znaczących nie jest w żadnej mierze zagadnieniem związanym z językiem Prolog, lecz należy do podstawowych wręcz problemów informatyki. Mogę jedynie spekulować na temat ewentualnych przyczyn błędów popełnionych przez część osób, lecz w tym momencie chciałbym przede wszystkim prosić, abyście Państwo następnym razem baczniejszą uwagę zwracali na takie - proste z istocie - rzeczy. Mam też nadzieję, że moje wyjaśnienie przybliży niektórym przeoczone przez nich kwestie i przysłuży się przy okazji kolejnego zaliczenia. Z poważaniem, Artur Michalski