Rozwiązanie zadania "CRC" #24

s426211 · 2018-06-15T17:15:59+02:00

s426211 commented

2018-06-15 17:15:59 +02:00

First-time contributor

No description provided.

kalmar commented

2018-06-25 15:10:53 +02:00

Proszę sprawdzić, że program jest w stanie zweryfikować swój output:
string Hello_world ma crc 0xc50e, który koduje Pan jako utf-16;
tymczasem na wyjściu kodowania powinien pojawić się bytecode.
(Dlatego właśnie było założenie o tym, że znaki są tylko ASCII, każdy reprezentowalny jako 8-bitowa liczba)

Proszę sprawdzić, że program jest w stanie zweryfikować swój output: string `Hello_world` ma crc `0xc50e`, który koduje Pan jako utf-16; tymczasem na wyjściu kodowania powinien pojawić się bytecode. (Dlatego właśnie było założenie o tym, że znaki są tylko ASCII, każdy reprezentowalny jako 8-bitowa liczba)

s426211 commented

2018-06-25 17:09:10 +02:00

First-time contributor

Dla stringa "Hello_world" program zwraca CRC o wartości 0xC50E, co, mam nadzieję, udowadnia załączony obrazek. Do kodu dodałem tylko wyświetlenie ramki w postaci heksadecymalnej.

Postaram się też pozbyć wszelkich wątpliwości:

a) Kodowanie
Zakres ASCII, przynajmniej w Pythonie 3, obejmuje zaledwie liczby 0 - 127. Co za tym idzie, dla niektórych wiadomości ramka się mieściła w tym zakresie, ale dla reszty nie.
Przykładem tego jest bajt powyżej: C5 (16) = 197 (10)
Rozwiązaniem była zamiana kodowania na latin-1 co powiększyło zakres do 255.

b) Treść zadania
Z treści zrozumiałem, że funkcja kodująca po wprowadzeniu "wiadomosc" zwróci "wiadomoscBB" gdzie BB to są dwa bajty, każdy z nich w postaci ASCII 8-bitowej.
Tak jak wspomniałem w a), zakres ASCII okazał się niewystarczający, więc żeby zobaczyć naszą zakodowaną wiadomość w konsoli (niekoniecznie z ramką drukowalną!) posłużyłem się innym sposobem.

Jeśli mam wprowadzić jakieś zmiany lub coś wytłumaczyć, służę pomocą.

Dla stringa "Hello_world" program zwraca CRC o wartości 0xC50E, co, mam nadzieję, udowadnia załączony obrazek. Do kodu dodałem tylko wyświetlenie ramki w postaci heksadecymalnej. Postaram się też pozbyć wszelkich wątpliwości: a) Kodowanie Zakres ASCII, przynajmniej w Pythonie 3, obejmuje zaledwie liczby 0 - 127. Co za tym idzie, dla niektórych wiadomości ramka się mieściła w tym zakresie, ale dla reszty nie. Przykładem tego jest bajt powyżej: C5 (16) = 197 (10) Rozwiązaniem była zamiana kodowania na latin-1 co powiększyło zakres do 255. b) Treść zadania Z treści zrozumiałem, że funkcja kodująca po wprowadzeniu "wiadomosc" zwróci "wiadomoscBB" gdzie BB to są dwa bajty, każdy z nich w postaci ASCII 8-bitowej. Tak jak wspomniałem w a), zakres ASCII okazał się niewystarczający, więc żeby zobaczyć naszą zakodowaną wiadomość w konsoli (niekoniecznie z ramką drukowalną!) posłużyłem się innym sposobem. Jeśli mam wprowadzić jakieś zmiany lub coś wytłumaczyć, służę pomocą.

scr.png

158 KiB

kalmar commented

2018-06-25 17:47:03 +02:00

wiem, że algorytm dzielenia zwraca poprawną odpowiedź;-)

niemniej nikt nie powiedział w specyfikacji, że wiadomość po dołączeniu FCS ma być "czytelnym ciągiem znaków ASCII", albo że w ogóle ma być ciągiem znaków w jakimkolwiek kodowaniu. Że tak się dzieje (po konwersji do innego kodowania), to czysty zbieg okoliczności ;-)

Notabene przechowując fcs w takiej postaci narażamy się na ewentualne problemy, gdy ktoś postanowi kiedyś zmienić kodowanie (co miejmy jednak nadzieję, że nie nastąpi w najbliższej przyszłości ;).

tak naprawdę wyjście powinno być typu bytearray (albo bytes)

>>> ba = bytearray('Hello_world', 'ascii')
>>> fcs = ... # liczymy FCS
>>> ba.append(fcs[0])
>>> ba.append(fcs[1])
>>> ba
bytearray(b'Hello world!\xc3\n')

przy sprawdzaniu fcs znowu nie możemy założyć, że dwa ostatnie bajty mieszczą się w ascii, więc musimy je obciąć:

>>> fcs = ba[-2:0]
>>> ... # sprawdzamy, że ten fcs jest poprawny 
>>> message = ba[0:-2].decode('ascii')

Czytając jeszcze raz widzę, że treść zadania nie jest do końca poprawnie sformułowana.

wiem, że algorytm dzielenia zwraca poprawną odpowiedź;-) niemniej nikt nie powiedział w specyfikacji, że wiadomość po dołączeniu FCS ma być "czytelnym ciągiem znaków ASCII", albo że w ogóle ma być ciągiem znaków w jakimkolwiek kodowaniu. Że tak się dzieje (po konwersji do innego kodowania), to czysty zbieg okoliczności ;-) Notabene przechowując fcs w takiej postaci narażamy się na ewentualne problemy, gdy ktoś postanowi kiedyś zmienić kodowanie (co miejmy jednak nadzieję, że nie nastąpi w najbliższej przyszłości ;). tak naprawdę wyjście powinno być typu `bytearray` (albo `bytes`) ```python >>> ba = bytearray('Hello_world', 'ascii') >>> fcs = ... # liczymy FCS >>> ba.append(fcs[0]) >>> ba.append(fcs[1]) >>> ba bytearray(b'Hello world!\xc3\n') ``` przy sprawdzaniu fcs znowu nie możemy założyć, że dwa ostatnie bajty mieszczą się w ascii, więc musimy je obciąć: ```python >>> fcs = ba[-2:0] >>> ... # sprawdzamy, że ten fcs jest poprawny >>> message = ba[0:-2].decode('ascii') ``` Czytając jeszcze raz widzę, że treść zadania nie jest do końca poprawnie sformułowana.

s426211 commented

2018-06-26 01:35:38 +02:00

First-time contributor

Wprowadziłem zmiany do procesu kodowania i dekodowania. Liczę, że teraz jest tak jak miało być. Dodatkowo, program uruchamia się teraz bezpośrednio z terminala za pomocą flag. Więcej informacji w fladze -h (bez żadnej wyświetlą się one automatycznie).

kalmar commented

2018-06-26 11:18:46 +02:00

na commicie f807d32:

$ python main.py -d abc\\x51\\x4a
Traceback (most recent call last):
  File "main.py", line 125, in <module>
    print(decode(sys.argv[2]))
  File "main.py", line 69, in decode
    fb = bin(int(fb, 16))[2:]
ValueError: invalid literal for int() with base 16: 'x5'

na commicie `f807d32`: ```bash $ python main.py -d abc\\x51\\x4a Traceback (most recent call last): File "main.py", line 125, in <module> print(decode(sys.argv[2])) File "main.py", line 69, in decode fb = bin(int(fb, 16))[2:] ValueError: invalid literal for int() with base 16: 'x5' ```

s426211 commented

2018-06-26 12:25:28 +02:00

First-time contributor

Teraz już naprawdę powinno działać.

kalmar commented

2018-06-26 20:05:30 +02:00

ok, uwagi do kodu:

czy naprawdę trzeba było operować na stringach? fragmenty typu str(hex(int(...))) wskazują, że chyba jednak nie ;-)
dlaczego nie użył Pan dzielenia wielomianów z poprzedniego zadania? Całe zadanie sprowadzałoby się do napisania funkcji która z ciągu znaków ascii wyprodukuje wielomian o współczynnikach w Z/2 i odwrotnie. + kodowanie ramki. Gdyby mnieć odpowiednio napisaną klasę Polynomial (przeciążającą __add__, __mul__, __pow__ i __mod__), czyli to co mieli Państwo przygotować w Zadaniu 2 możnaby napisać:

def fcs(msg):
    bits = bits_from_string(msg) # zmyślam nazwy
    M = Polynomial(2, bits)
    L = Polynomial(2, [1]*16)
    x = Polynomial(2, [0,1])
    G = 1 + x**5 + x**12 + x**16
    
    fcs = (x**16*Mx + X**(len(bits)-16)*L) % G
    
    return bits_to_bytearray(fcs.coeffs)

ok, uwagi do kodu: 1. czy naprawdę trzeba było operować na stringach? fragmenty typu `str(hex(int(...)))` wskazują, że chyba jednak nie ;-) 2. dlaczego nie użył Pan dzielenia wielomianów z poprzedniego zadania? Całe zadanie sprowadzałoby się do napisania funkcji która z ciągu znaków ascii wyprodukuje wielomian o współczynnikach w Z/2 i odwrotnie. + kodowanie ramki. Gdyby mnieć odpowiednio napisaną klasę `Polynomial` (przeciążającą `__add__`, `__mul__`, `__pow__` i `__mod__`), czyli to co mieli Państwo przygotować w Zadaniu 2 możnaby napisać: ```python def fcs(msg): bits = bits_from_string(msg) # zmyślam nazwy M = Polynomial(2, bits) L = Polynomial(2, [1]*16) x = Polynomial(2, [0,1]) G = 1 + x**5 + x**12 + x**16 fcs = (x**16*Mx + X**(len(bits)-16)*L) % G return bits_to_bytearray(fcs.coeffs) ```

kalmar closed this pull request

2018-06-29 00:29:08 +02:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

No reviewers

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: kalmar/DALGLI0#24