Existe-t-il un moyen d'utiliser des demi-bits?

Comme la plupart des gens ici le savent, en utilisant 4 bits, nous pouvons compter de 0 à 15 (0123456789ABCDEF en hexadécimal). Mais si nous devions seulement compter jusqu'à 9, nous utiliserions toujours 4 bits et les chiffres de A à F seraient gaspillés.

Cependant, la page QR-Code de Wikipedia indique que l'utilisation uniquement de chiffres numériques de 0 à 9 utilise 3⅓ bits par caractère, ce qui est correct d'un point de vue statistique. Et pourtant, un tiers de bit n'est pas un objet physique, et l'envoi d'un nombre de 0 à 9 utilise au moins 4 bits à ma connaissance.

Existe-t-il un moyen d'utiliser les combinaisons gaspillées pour envoyer efficacement un caractère avec des fractions de bits?

OK, permettez-moi de donner un exemple: les deux chiffres "27" doivent être envoyés. Avec des techniques de codage normales, les bits envoyés seraient 00100111. On pourrait alors imaginer un système qui remplacerait le chiffre «2» par le chiffre «E» ou «F», selon le bit suivant; dans ce cas, le bit suivant est 0, donc le «2» est remplacé par «E». La chaîne de bits résultante serait alors 1101 0 111. En revanche, si les chiffres "28" doivent être envoyés, le premier bit après le "2" est un 1, il est donc remplacé par le chiffre "F" à la place, donnant la chaîne 1111 1 000.

Dans les deux cas, une économie de 1 bit a été effectuée, car un quartet a été utilisé pour deux caractères différents. En d'autres termes, trois bits et demi sont utilisés sur chaque caractère.

Vous ne pouvez pas envoyer un demi-bit, mais vous pouvez effectivement emballer deux demi-bits en un seul bit avant la transmission ou le stockage.

Vous donnez vous-même un exemple, vous avez donc effectivement répondu à votre propre question par un OUI.

Un moyen peut-être un peu plus simple consiste à coder simplement la valeur de deux chiffres décimaux en 7 bits. (Sorte de codage binaire à deux décimales).

Vous pouvez utiliser le codage Huffman pour que les nombres soient de longueur variable. si vous connaissez un chiffre qui se produira plus souvent que d'autres, cela vous aidera.

exemple (avec occurrence égale):

0 - 1111

1 - 1110

2 - 110

3 - 101

4 - 100

5 - 011

6 - 010

7 - 001

8 - 000

exemple de réception pour obtenir le numéro 1:

Le premier bit entre et ne laisse que 0 à 4 en option.

le deuxième bit entre et ne laisse que 0 à 2 en option.

le troisième bit entre et laisse 0 à 1 en option.

le quatrième bit entre et le nombre entrant est 1

Peut-être que vous recherchez un codage arithmétique, qui peut encoder efficacement une chaîne de symboles, dont chacun peut en principe nécessiter un nombre fractionnaire (non entier) de bits. (bien que le message total doive être un nombre entier de bits)

Citant Wikipédia :

Le codage arithmétique diffère des autres formes de codage entropique comme le codage Huffman en ce que, plutôt que de séparer l'entrée en symboles de composants et de les remplacer par un code, le codage arithmétique code le message entier en un seul numéro, une fraction n où (0,0 ≤ n < 1.0).

Le nouvel IEEE P754 pour l'arithmétique à virgule flottante définit désormais les formats décimaux en plus du binaire. L'un des encodages propose de regrouper les chiffres numériques de 3 en 10 bits.

encoder de 0 à 999 en utilisant 10 bits = 1024 codes possibles est assez efficace, et les chiffres décimaux sont souvent groupés par trois de toute façon.

Décimal emballé de façon dense : http://en.wikipedia.org/wiki/Densely_packed_decimal

Une correspondance 1: 1 de binaire (ou hexadécimal) n'est qu'un codage de symbole pour les bits. Alors oui, comme vous l'avez montré, c'est possible. Un autre endroit utilisé (mais légèrement différent) est le codage / décodage en treillis dans les systèmes de communication dans lesquels les transitions de bits sont maintenues plus éloignées pour faciliter le décodage. Et bien sûr, l'encodage 8b / 10b et 64b / 66b etc.

La représentation des données dépend de l'interprétation que vous ou votre programme lui donne.

Nous pourrions envoyer «27» également sous forme de caractères ASCII, par exemple, en donnant 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$ bits.

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

Cela dépend toujours de l'application, mais normalement lorsque vous «joignez» des variables comme vous le suggérez, cela coûtera plus de puissance de calcul si vous souhaitez effectuer des opérations sur ces variables. L'ajout et la soustraction d'opérations sur des variables «jointes» sont plus complexes que d'habitude et peuvent nécessiter plus d'espace dans le matériel, ou entraîner des délais plus longs.

$\lceil\dots\rceil$

La façon habituelle de compresser les valeurs consiste à multiplier chaque valeur par sa plage, de sorte que vous vous retrouvez avec un grand nombre que vous pouvez représenter efficacement en bits. Lors du déballage, vous divisez par plage, le reste est le chiffre et le résultat est le reste des chiffres compressés.

Si vous avez 5 valeurs dans la plage de 0 à 2, vous pouvez représenter cela sur 8 bits (vous avez besoin d'au moins 7,92 bits pour représenter les valeurs) au lieu des 10 bits utilisés par la manière naïve d'utiliser 2 bits pour chaque valeur, en faisant (((n ₁ * 3 + n ₂ ) * 3 + n ₃ ) * 3 + n ₄ ) * 3 + n ₅

En théorie, si vous êtes prêt à dépenser de l'espace de circuit et de l'énergie pour le détecteur à haute impédance, vous pouvez envoyer 3 états sur un fil numérique (1, 0 et Z élevé). Avertissement: cela fonctionne très bien dans le simulateur. Je ne sais pas si le circuit a des problèmes qui le rendent impraticable, comme dire qu'il ne peut pas vraiment commuter aussi vite qu'une paire normale de portes.

Mon terme normal pour une transition de signal d'un Z élevé au signal (où le signal est généralement mis à la terre dans du silicium) est un signal demi-bit.

Vous souhaitez envoyer un chiffre décimal, nécessitant 3⅓ bits. Mais vous devrez utiliser 4 bits, car vous ne pouvez pas envoyer un tiers de bit.

Donc, pour savoir ce que signifie réellement 3⅓ bits, vous avez besoin de deux (ou trois) chiffres de 3⅓ bits chacun. Si vous souhaitez envoyer 2 (3) chiffres décimaux entre 0 et 9, chacun nécessitant un peu moins de 3⅓ bits, vous pouvez le faire en utilisant 7 (10) bits. La preuve constructive est facile:

7 (10) bits vous permettent d'encoder un nombre compris entre 0 et 128 (1023) - mais vous n'aurez besoin que de 00 (000) à 99 (999), qui sont tous des encodages possibles de deux (trois) chiffres décimaux. QED

Je pense que vous ne comprenez pas bien ce que signifie l'article wiki lié. Qu'est - ce que l' on entend est que pour une chaîne de caractères qui est complètement numérique (sans espaces, virgules, ou périodes), en utilisant la compression idéale, vous pouvez représenter chaque caractère en utilisant 3 ¹ / ₃ des bits en moyenne . En fait, c'est un peu mieux que cela, car les calculs disent que vous pouvez obtenir le journal ₂ (10) = 3,3219 bits / caractère à long terme.

De même, pour l'ensemble alphanumérique plus certains symboles (majuscules uniquement et 9 symboles) ou 45 caractères, vous avez besoin du journal ₂ (45) = 5,4918 bits / caractère, qui est arrondi à 5,5 dans l'article.

Les bits / caractères réduits sont obtenus en utilisant la compression, soit avec un encodage prédéfini, soit avec un schéma de compression spécifié par la norme QR (je ne sais pas lequel est utilisé). Il représente le nombre moyen de bits dont un caractère aura besoin pour être codé, donc un caractère individuel sera codé en utilisant plus ou moins de bits. Sachez également que les valeurs répertoriées ci-dessus sont les valeurs idéales pour des chaînes infinies et aléatoires. Il est possible d'obtenir des taux de compression meilleurs ou pires pour les cordes spécialement conçues.