Existe alguma maneira de usar meio bits?

Como a maioria das pessoas sabe, usando 4 bits, podemos contar de 0 a 15 (0123456789ABCDEF em hexadecimal). Mas se contássemos até 9, ainda estaríamos usando 4 bits, e os dígitos de A a F seriam desperdiçados.

No entanto, a página QR-Code da Wikipedia afirma que o uso apenas de dígitos numéricos de 0 a 9 usa 3⅓ bits por caractere, o que é correto do ponto de vista estatístico. E, no entanto, um terço de um bit não é um objeto físico, e o envio de um número de 0 a 9 usa pelo menos 4 bits, pelo que sei.

Existe alguma maneira de usar as combinações desperdiçadas para enviar efetivamente um personagem com frações de bits?

OK, deixe-me dar um exemplo: Os dois dígitos "27" devem ser enviados. Com técnicas normais de codificação, os bits enviados seriam 00100111. Poderíamos então imaginar um sistema que substituísse o dígito '2' pelo dígito 'E' ou 'F', dependendo do próximo bit; neste caso, o próximo bit é 0, então o '2' é substituído por 'E'. A sequência de bits resultante seria 1101 0 111. Por outro lado, se os dígitos "28" tiverem que ser enviados, o primeiro bit após o '2' será 1, sendo substituído pelo dígito 'F', produzindo a sequência 1111 1 000.

Nos dois casos, uma economia de 1 bit foi efetuada, porque uma mordidela foi usada para dois caracteres diferentes. Em outras palavras, três bits e meio são usados ​​em cada caractere.

Você não pode enviar meio bit, mas pode efetivamente empacotar dois meio bits em um bit antes da transmissão ou armazenamento.

Você mesmo dá um exemplo e efetivamente respondeu sua própria pergunta com um SIM.

Uma maneira talvez um pouco mais fácil é codificar o valor de dois dígitos decimais em 7 bits. (Tipo de decimal decimal com código binário).

Você pode usar a codificação huffman para que os números tenham diferentes tamanhos de bits. se você estiver ciente de um dígito que ocorrerá com mais frequência do que outros, isso ajudará.

exemplo (com igual ocorrência):

0 - 1111

1 - 1110

2 - 110

3 - 101

4 - 100

5 - 011

6 - 010

7 - 001

8 - 000

exemplo de recebimento final para obter o número 1:

O primeiro bit entra e deixa apenas 0 a 4 como opções.

o segundo bit entra e deixa apenas 0 a 2 como opções.

o terceiro bit entra e deixa 0 a 1 como opções.

o quarto bit entra e o número recebido é 1

Talvez o que você esteja procurando seja a codificação aritmética, que pode codificar com eficiência uma sequência de símbolos, cada um dos quais em princípio pode exigir um número fracionário (não inteiro) de bits. (embora a mensagem total deva ser um número inteiro de bits)

Citando a Wikipedia :

A codificação aritmética difere de outras formas de codificação de entropia, como a codificação de Huffman, em vez de separar a entrada em símbolos componentes e substituir cada uma por um código, a codificação aritmética codifica a mensagem inteira em um único número, uma fração n onde (0,0 ≤ n < 1.0).

O novo IEEE P754 para aritmética de ponto flutuante agora define formatos decimais além de binários. Uma das codificações propõe agrupar dígitos digitais por 3 em 10 bits.

codificar de 0 a 999 usando 10bits = 1024 códigos possíveis é bastante eficiente, e os dígitos decimais geralmente são agrupados por três.

Decimal densamente compactado : http://en.wikipedia.org/wiki/Densely_packed_decimal

Uma correspondência 1: 1 de binário (ou hexadecimal) é apenas um símbolo de codificação para bits. Então sim, como você mostrou, é possível. Outro local usado é (mas um pouco diferente) na treliça de codificação / decodificação em sistemas de comunicação em que as transições de bits são mantidas mais afastadas para facilitar a decodificação. E, é claro, a codificação 8b / 10b e 64b / 66b etc. etc. é uma idéia semelhante, na qual um espaço menor de símbolo é codificado em um espaço maior ligeiramente redundante para obter equilíbrio de DC, separação de símbolos e códigos de controle em sub-bandas.

A representação dos dados depende da interpretação que você ou seu programa fornece.

Poderíamos enviar '27' também como caracteres ASCII, por exemplo, produzindo 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$

Sempre depende da aplicação, mas normalmente quando você 'junta' variáveis ​​como você sugere, custará mais poder computacional se você quiser executar operações nessas variáveis. As operações de adição e subtração de variáveis ​​'unidas' são mais complexas do que o normal e podem exigir mais espaço no hardware ou causar atrasos maiores.

$\lceil\dots\rceil$

A maneira usual de empacotar valores é multiplicando cada valor pelo seu intervalo, para que você tenha um número grande que possa representar eficientemente em bits. Ao desembalar, você divide por faixa, o restante é o dígito e o resultado são os demais dígitos empacotados.

Se você tiver 5 valores no intervalo de 0 a 2, poderá representá-lo em 8 bits (você precisa de pelo menos 7,92 bits para representar os valores) em vez dos 10 bits usados ​​pela maneira ingênua de usar 2 bits para cada valor, fazendo (((n ₁ * 3 + n ₂ ) * 3 + n ₃ ) * 3 + n ₄ ) * 3 + n ₅

Em teoria, se você estiver disposto a gastar espaço em circuito e energia no detector de alta impedância, poderá enviar três estados por um fio digital (1, 0 e Z alto). Isenção de responsabilidade: isso funciona muito bem no simulador. Não sei se o circuito tem alguns problemas que o tornam impraticável, como dizer que ele não pode realmente mudar tão rápido quanto um par de portas normal.

Meu termo normal para a transição de um sinal de Z alto para um sinal (onde o sinal geralmente é aterrado em silício) é um sinal de meio bit.

Você deseja enviar um dígito decimal, precisando de 3 bits. Mas você terá que usar 4 bits, porque não pode enviar um terço de um bit.

Portanto, para descobrir o que realmente significa 3 bits, você precisa de dois (ou três) dígitos de 3 bits cada. Se você quiser enviar 2 (3) dígitos decimais entre 0 e 9, cada um precisando um pouco menos de 3⅓ bits, poderá fazê-lo usando 7 (10) bits. A prova construtiva é fácil:

7 (10) bits permitem codificar um número entre 0 e 128 (1023) - mas você precisará apenas de 00 (000) a 99 (999), que são todas possíveis codificações de dois (três) dígitos decimais. QED

Acho que você está entendendo mal o que se entende no artigo wiki vinculado. O que se entende é que para uma cadeia de caracteres que é completamente numérico (sem espaços, vírgulas ou períodos), usando compressão ideal, pode representar cada caractere usando 3 ¹ / ₃ pedaços , em média . Na verdade, é um pouco melhor que isso, pois a matemática diz que você pode obter o log ₂ (10) = 3,3219 bits / caractere a longo prazo.

Da mesma forma, para o conjunto de alfanuméricos mais alguns símbolos (somente maiúsculas e 9 símbolos) ou 45 caracteres, é necessário registrar ₂ (45) = 5,4918 bits / caractere, arredondado para 5,5 no artigo.

Os bits / caracteres reduzidos são alcançados usando a compactação, com uma codificação predefinida ou um esquema de compactação especificado pelo padrão QR (não sei ao certo qual é usado). Ele representa o número médio de bits que um caractere precisará para ser codificado; portanto, um caractere individual será codificado usando mais ou menos bits. Observe também que os valores listados acima são os valores ideais para seqüências infinitas e aleatórias. É possível obter taxas de compactação melhores ou piores para cadeias especialmente criadas.