Czy jest jakiś sposób na użycie półbitów?

Jak większość ludzi tutaj wie, używając 4 bitów jesteśmy w stanie policzyć od 0 do 15 (0123456789ABCDEF w systemie szesnastkowym). Ale gdybyśmy policzyli tylko do 9, nadal używalibyśmy 4 bity, a cyfry od A do F byłyby zmarnowane.

Jednak strona z kodem QR Wikipedii stwierdza, że ​​użycie tylko cyfr od 0 do 9 używa 3⅓ bitów na znak, co jest poprawne z statystycznego punktu widzenia. A jednak jedna trzecia bitu nie jest przedmiotem fizycznym, a wysłanie numeru od 0 do 9 wykorzystuje moją wiedzę o co najmniej 4 bitach.

Czy istnieje sposób na wykorzystanie zmarnowanych kombinacji, aby skutecznie wysłać postać z ułamkami bitów?

OK, podaję przykład: Dwie cyfry „27” muszą zostać wysłane. Przy normalnych technikach kodowania wysyłane bity miałyby wartość 00100111. Moglibyśmy wówczas wyobrazić sobie system, który zastąpiłby cyfrę „2” cyfrą „E” lub „F”, w zależności od następnego bitu; w tym przypadku następnym bitem jest 0, więc „2” zastępuje się „E”. Wynikowy ciąg bitów wynosiłby wtedy 1101 0 111. Z drugiej strony, jeśli cyfry „28” muszą zostać wysłane, pierwszy bit po „2” to 1, więc zamiast tego jest zastępowany cyfrą „F”, uzyskując ciąg 1111 1 000.

W obu przypadkach uzyskano oszczędność 1 bitu, ponieważ dla dwóch różnych znaków użyto jednego skrawka. Innymi słowy, trzy i pół bitu są używane na każdym znaku.

Nie możesz wysłać pół bita, ale możesz skutecznie spakować dwa półbity w jednym bicie przed transmisją lub przechowywaniem.

Dajesz przykład sam, więc skutecznie odpowiedziałeś na swoje pytanie TAK.

Być może nieco łatwiejszym sposobem jest proste zakodowanie wartości dwóch cyfr dziesiętnych w 7 bitach. (Rodzaj podwójnie dziesiętnego kodowanego binarnie).

Możesz użyć kodowania Huffmana, aby liczby miały różną długość bitów. jeśli znasz cyfrę, która pojawi się częściej niż inne, to pomoże.

przykład (z równym wystąpieniem):

0–1111

1 - 1110

2 - 110

3 - 101

4 - 100

5 - 011

6 - 010

7 - 001

8 - 000

przykład odbioru na końcu dla uzyskania numeru 1:

Wchodzi pierwszy bit i pozostawia tylko 0 do 4 jako opcje.

wchodzi drugi bit i pozostawia tylko 0 do 2 jako opcje.

trzeci bit wchodzi i pozostawia 0 do 1 jako opcje.

pojawia się czwarty bit, a liczba przychodząca to 1

Być może szukasz kodowania arytmetycznego, które może efektywnie kodować ciąg symboli, z których każdy w zasadzie może wymagać ułamkowej (niecałkowitej) liczby bitów. (chociaż łączna wiadomość musi zawierać całą liczbę bitów)

Cytując Wikipedię :

Kodowanie arytmetyczne różni się od innych form kodowania entropijnego, takich jak kodowanie Huffmana tym, że zamiast rozdzielać dane wejściowe na symbole składowe i zastępować je kodem, kodowanie arytmetyczne koduje całą wiadomość na pojedynczą liczbę, ułamek n gdzie (0,0 ≤ n < 1.0).

Nowy IEEE P754 do arytmetyki zmiennoprzecinkowej oprócz formatów binarnych definiuje teraz również formaty dziesiętne. Jedno z kodowań proponuje pogrupowanie cyfr cyfrowych według 3 na 10 bitów.

kodowanie od 0 do 999 przy użyciu 10 bitów = 1024 możliwych kodów jest dość wydajne, a cyfry dziesiętne są często i tak pogrupowane według trzech.

Gęsto zapakowany po przecinku : http://en.wikipedia.org/wiki/Densely_packed_decimal

Korespondencja binarna (lub szesnastkowa) 1: 1 to tylko jeden symbol kodujący bity. Tak, jak pokazałeś, jest to możliwe. Innym miejscem, w którym jest to używane, jest (ale nieco inaczej) kodowanie / dekodowanie kraty w systemach komunikacyjnych, w których przejścia bitów są umieszczone dalej od siebie, aby ułatwić dekodowanie. I oczywiście kodowanie 8b / 10b i 64b / 66b itp. Itd. Jest podobnym pomysłem, w którym mniejsza przestrzeń symboli jest kodowana w nieco redundantnej większej przestrzeni, aby uzyskać kody równowagi DC, separacji symboli i kontroli w podpasmach.

Reprezentacja danych zależy od interpretacji, którą Ty lub Twój program je podajesz.

Możemy wysłać „27” również jako znaki ASCII, na przykład, dając 0x3237 = 0b0011001000110111.

$x$$n(x)$${\lceil\log_2{n(x)}\rceil}$

$x_1,x_2$$n(x_1),n(x_2)$$\lceil\log_2n(x_1)\rceil+\lceil\log_2n(x_2)\rceil$$\left\lceil\log_2\left(n(x_1)\cdot n(x_2)\right)\right\rceil$

$2\cdot\lceil\log_2(10)\rceil=2\cdot4=8$$\lceil\log_2(10\cdot10)\rceil=7$

Zawsze zależy to od aplikacji, ale zwykle, kiedy „łączysz” zmienne, jak sugerujesz, będzie to kosztować więcej mocy obliczeniowej, jeśli chcesz wykonywać operacje na tych zmiennych. Dodawanie i odejmowanie operacji na zmiennych „połączonych” jest bardziej złożone niż zwykle i może wymagać więcej miejsca w sprzęcie lub powodować dłuższe opóźnienia.

$\lceil\dots\rceil$

Zwykle sposób pakowania wartości polega na pomnożeniu każdej wartości przez jej zakres, dzięki czemu otrzymujesz jedną dużą liczbę, którą możesz skutecznie przedstawić w bitach. Podczas rozpakowywania dzielisz według zakresu, reszta to cyfra, a wynikiem są pozostałe spakowane cyfry.

Jeśli masz 5 wartości z zakresu od 0 do 2, możesz przedstawić to w 8 bitach (potrzebujesz co najmniej 7,92 bitów do przedstawienia wartości) zamiast 10 bitów używanych przez naiwny sposób używania 2 bitów dla każdej wartości, wykonując (((n ₁ * 3 + n ₂ ) * 3 + n ₃ ) * 3 + n ₄ ) * 3 + n ₅

Teoretycznie, jeśli chcesz wydać przestrzeń i energię na detektor o wysokiej impedancji, możesz wysłać 3 stany cyfrowym przewodem (1, 0 i wysokie Z). Oświadczenie: działa świetnie w symulatorze. Nie wiem, czy w obwodzie występują jakieś problemy, które sprawiają, że jest niepraktyczny, na przykład nie można tak szybko zmienić się jak zwykła para bram.

Mój normalny termin przejścia sygnału z wysokiej Z na sygnał (gdzie sygnał jest zwykle uziemiony w krzemie) to sygnał półbitowy.

Chcesz wysłać jedną cyfrę dziesiętną, wymagającą 3⅓ bitów. Ale będziesz musiał użyć 4 bitów, ponieważ nie możesz wysłać jednej trzeciej.

Tak więc, aby dowiedzieć się, co tak naprawdę oznaczają 3, bity, potrzebujesz dwóch (lub trzech) cyfr po 3⅓ bitu każdy. Jeśli chcesz wysłać 2 (3) cyfry dziesiętne z przedziału od 0 do 9, z których każda wymaga nieco mniej niż 3⅓ bitów, możesz to zrobić przy użyciu 7 (10) bitów. Konstruktywny dowód jest łatwy:

7 (10) bitów pozwala ci zakodować liczbę od 0 do 128 (1023) - ale potrzebujesz tylko 00 (000) do 99 (999), które wszystkie są możliwymi kodowaniami dwóch (trzech) cyfr dziesiętnych. CO BYŁO DO OKAZANIA

Myślę, że nie rozumiesz, co oznacza linkowany artykuł wiki. Co to znaczy, że na ciąg znaków, który jest całkowicie liczbowa (bez spacji, przecinków, lub okresów), przy użyciu kompresji idealne, można reprezentować każdy znak przy użyciu 3 ¹ / ₃ bity na średniej . W rzeczywistości jest to nieco lepsze, ponieważ matematyka mówi, że możesz uzyskać log ₂ (10) = 3,3219 bitów / znak na dłuższą metę.

Podobnie, dla zestawu znaków alfanumerycznych plus niektórych symboli (tylko wielkie litery i 9 symboli) lub 45 znaków, potrzebujesz log ₂ (45) = 5,4918 bitów / znak, który jest zaokrąglany w górę do 5,5 w artykule.

Zmniejszoną liczbę bitów / znaków uzyskuje się za pomocą kompresji, albo ze wstępnie ustawionym kodowaniem, albo ze schematu kompresji określonego przez standard QR (nie jestem pewien, który jest używany). Reprezentuje średnią liczbę bitów potrzebnych do zakodowania znaku, więc pojedynczy znak będzie zakodowany przy użyciu większej lub mniejszej liczby bitów. Pamiętaj również, że wartości wymienione powyżej są wartościami idealnymi dla nieskończonych, losowych ciągów. Możliwe jest uzyskanie lepszych lub gorszych współczynników kompresji dla specjalnie wykonanych strun.