Чи є спосіб використання напівбітів?

Як знає більшість людей тут, використовуючи 4 біти, ми можемо нарахувати від 0 до 15 (0123456789ABCDEF у шістнадцятковій кількості). Але якби ми рахували лише до 9, ми все-таки використовували б 4 біти, а цифри від А до F були б марними.

Однак на сторінці QR-коду у Вікіпедії зазначено, що для використання лише числових цифр від 0 до 9 використовується 3⅓ біт на символ, що є правильним з точки зору статистичної позиції. І все ж третина біта - це не фізичний об’єкт, і для надсилання числа від 0 до 9, на мою інформацію, використовується щонайменше 4 біти.

Чи є спосіб використовувати витрачені комбінації для ефективного надсилання символу з дробами бітів?

Добре, дозвольте навести приклад: дві цифри "27" повинні бути надіслані. З нормальними методами кодування, надіслані біти будуть 00100111. Потім ми могли б уявити систему, яка замінить цифру '2' цифрою 'E' або 'F', залежно від наступного біта; у цьому випадку наступний біт дорівнює 0, тому "2" замінюється на "E". Отриманий бітовий рядок буде тоді 1101 0 111. З іншого боку, якщо цифри "28" повинні бути надіслані, перший біт після "2" - це 1, тож замість нього замінюється цифра "F", виходить рядок 1111 1 000.

В обох випадках було досягнуто економність 1 біта, тому що один клювач був використаний для двох різних символів. Іншим словом, на кожен символ використовується три з половиною біти.

Ви не можете надіслати півбіт, але ви можете ефективно упакувати два половини біта в один біт перед передачею або зберіганням.

Ви самі наводите приклад, так що ви ефективно відповіли на власне запитання ДА.

Можливо, дещо простішим способом є просте кодування значення двох десяткових цифр у 7 біт. (Сортування двійкових кодованих подвійних десятків).

Ви можете використовувати кодування Huffman, так що числа мають різну довжину бітів. якщо ви знаєте цифру, яка відбуватиметься частіше за інших, це допоможе.

приклад (з рівним виникненням):

0 - 1111

1 - 1110

2 - 110

3 - 101

4 - 100

5 - 011

6 - 010

7 - 001

8 - 000

приклад прийому для отримання числа 1:

Перший біт надходить і залишає лише 0 - 4 як варіанти.

другий біт надходить і залишає лише 0 - 2 як варіанти.

третій біт надходить і залишає 0 до 1 як варіанти.

надходить четвертий біт, і вхідне число - 1

Можливо, те, що ви шукаєте, - це арифметичне кодування, яке може ефективно кодувати рядок символів, кожен з яких в принципі може зажадати дробової (не цілої) кількості біт. (хоча загальне повідомлення має бути цілою кількістю біт)

Цитуючи Вікіпедію :

Арифметичне кодування відрізняється від інших форм ентропійного кодування, таких як кодування Хаффмана, тим, що замість того, щоб розділяти вхід на символи компонентів і замінювати кожен кодом, арифметичне кодування кодує все повідомлення в одне число, дробу n де (0,0 ≤ n < 1,0).

Новий IEEE P754 для арифметики з плаваючою комою тепер визначає десяткові формати на додаток до двійкових. Одне з кодування пропонує згрупувати цифрові цифри по 3 на 10 біт.

кодування від 0 до 999 з використанням 10 біт = 1024 можливих кодів є досить ефективним, а десяткові цифри часто згруповані за трьома.

Десяткове ущільнення : http://en.wikipedia.org/wiki/Densely_packed_decimal

1: 1 відповідність двійкової (або шістнадцяткової) є лише одним символом, що кодує біти. Так що так, як ви показали, це можливо. Інше місце, яке використовується, є (але дещо по-іншому) - в кодуванні / декодуванні решітки в системах зв'язку, в яких бітові переходи тримаються далі, щоб полегшити декодування. І звичайно, кодування 8b / 10b та 64b / 66b і т. Д. Тощо - це аналогічна ідея, в якій менший простір символів кодується в дещо зайвому просторі, щоб отримати баланс постійного струму, розділення символів та керування кодами в піддіапазонах.

Представлення даних залежить від інтерпретації, яку ви або ваша програма надає.

Ми можемо надіслати "27" також як ASCII символи, наприклад, поступаючись 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$

Це завжди залежить від програми, але зазвичай, коли ви 'приєднуєте' змінні, як ви пропонуєте, це буде коштувати більше обчислювальної потужності, якщо ви хочете виконувати операції над цими змінними. Операції додавання і віднімання змінних "з'єднаних" є складнішими, ніж зазвичай, і можуть зажадати більше місця в апаратному забезпеченні або викликати більш тривалі затримки.

$\lceil\dots\rceil$

Звичайний спосіб упаковки значень - це множення кожного значення на його діапазон, так що ви отримуєте одне велике число, яке ви можете ефективно представити в бітах. При розпакуванні ви ділите по діапазону, решта - цифра, а результат - решта упакованих цифр.

Якщо у вас є 5 значень в діапазоні від 0 до 2, ви можете представити це в 8 бітах (вам потрібно щонайменше 7,92 біта для представлення значень) замість 10 біт, використовуваних наївним способом використання 2 біт для кожного значення, виконуючи (((n ₁ * 3 + n ₂ ) * 3 + n ₃ ) * 3 + n ₄ ) * 3 + n ₅

Теоретично, якщо ви готові витратити простір ланцюга та потужність на детектор високого опору, ви можете надіслати 3 стани цифровим проводом (1, 0 і високий Z). Відмова від відповідальності: це чудово працює в тренажері. Я не знаю, чи є в ланцюзі якісь проблеми, які роблять це непрактичним, скажімо, він не може переключитися так швидко, як звичайна пара воріт.

Мій звичайний термін для переходу сигналу від високого Z до сигналу (де сигнал, як правило, мелений у кремнію), є напіврозрядним сигналом.

Ви хочете надіслати одну десяткову цифру, для цього потрібно 3⅓ біт. Але вам доведеться використовувати 4 біти, тому що ви не можете надіслати третину біта.

Отже, щоб дізнатися, що насправді означає 3⅓ біт, вам потрібно дві (або три) цифри по 3⅓ біт кожен. Якщо ви хочете надіслати 2 (3) десяткових цифр від 0 до 9, кожна з яких потребує трохи менше 3⅓ біт, ви можете зробити це, використовуючи 7 (10) біт. Конструктивне доведення легко:

7 (10) біт дозволяють кодувати число від 0 до 128 (1023) - але вам знадобиться лише від 00 (000) до 99 (999), які є усіма можливими кодуваннями двох (трьох) десяткових цифр. QED

Я думаю, ви нерозумієте, що мається на увазі у зв’язаній статті wiki. Що мається в виду , що для рядка символів, яка повністю числова (без пробілів, ком або періодів), використовуючи ідеальну компресію, ви можете представляти кожен символ , використовуючи 3 ⁺¹ / ₃ біта в середньому . Насправді, це трохи краще, ніж це, оскільки математика говорить, що ви можете отримати log ₂ (10) = 3.3219 біт / символ у довгостроковій перспективі.

Аналогічно, для набору буквено-цифрових знаків плюс деяких символів (лише великі регістри та 9 символів) або 45 символів потрібно журнал ₂ (45) = 5,4918 біт / символ, який округлюється до 5,5 у статті.

Зменшені біти / символи досягаються за допомогою стиснення або заздалегідь заданого кодування, або схеми стиснення, визначеної стандартом QR (я не впевнений, який використовується). Він представляє середню кількість бітів, які знадобиться символу для кодування, тому окремий символ буде закодований за допомогою більш-менш бітів. Також зрозумійте, що перелічені вище значення є ідеальними значеннями для нескінченних, випадкових рядків. Можна отримати коефіцієнти стиснення, які кращі чи гірші для спеціально створених рядків.