Technique de Codage

Bonjour,
Je recherche des infos (Algo, méthode(s)).. pour coder une information.

Je précise: Je dispose d'une nombre généré sur 11 Bytes
soit NBR.a = 01234567891,
Et NBR.b est du même format que NBR.a

Il n'est pas possible d'augmenter, ni de diminuer la taille de ce format.

Je suis contraint de devoir 'intégrer' à ce nombre une information type Oui, Non, que je nommerai Code.

Je cherche une fonction (Algo) telle que.
Au niveau de l'émetteur : f(NBR.a + CODE)= NBR.b
L'émetteur envoie au récepteur NBR.B

Au niveau du Récepteur: Il fait fonctionner sa 'Fonction inverse' soit
f-1(NBR.B)=NBR.a + Code

Le récepteur doit être capable, via la fonction inverse, de retrouver NBR.a ET le Code.

L'idée n'est pas de crypter l'information, mais bien d'intégrer une information supplémentaire à une donnée, sans modifier sa taille.

Merci pour vos infos et/ou vos liens pour que je puisse trouver une solution à ce problème.

Si j'ai bien compris, tu cherche à stocker dans un nombre à 88 bits (NBR.b, 8*11 bytes) un nombre à 88 bits (NBR.a) plus un nombre à 1 bit (Code).

Si c'est ça, ce n'est évidement pas possible, il faudrait au moins 89 bits.

Tes nombre NBR.a sont répartis comment statistiquement (valeur quelconque aléatoire à probablité uniforme) ?

Car si ce n'est pas trop aléatoire, il pourrait y avoir une solution.

Je ne peux pas modifer la taille, ça c'est certain.

Mais je suis quasi certain qu'il doit y avoir un moyen d'incorporer l'info simple dans ces 11 bytes.

En fait, c'est la fonction qui fait le boulot !
Elle est connue du recepteur et de l'émetteur .

Je ne sais pas comment ce nombre est généré.
Mais puisqu'il est issu d'un algo , il n'est pas aléatoire du tout.

Le seul moyen possible (mais ça reste à vérifier), c'est de compresser
ton nombre NBR.a selon une représentation en base n (n restant à choisir correctement) par exemple par un algo du type Arbre de compression de Huffman.

En théorie ça devrait pouvoir te libérer des bits pour stocker ton code.
Seulement dans la pratique, comme tu n'as que 88 bits ça risque d'être ric-rac.

Effectivement, c'est une solution.
Compresser le nombre de 88 bits afin de dégager un bit.

Non, pas vraiment, compresser permet de gagner de la place *en moyenne*, c'est à dire que les valeurs les plus fréquentes seront codées avec moins de 88 bits, mais la contre partie est que les valeurs les moins fréquentes nécessiterons plus de 88 bits.

Le problème ne peut avoir une solution que si le nombre NBR.a n'utilise pas toutes les valeurs possibles parmi les 11 bytes.

Dans le problème que tu soulève, une autre solution est envisageable :

- bufferiser l'emission pour découper la séquence de chiffres NBR.b de 12 bits en séquences de chiffres de 11 bits (les bits supplémentaires sont enfilés dans une file d'attente, pour emission lors du prochain envoi)
- ce principe est analogue à celui de retenue en addition binaire

Citation:

---

Si j'ai bien compris, tu cherche à stocker dans un nombre à 88 bits (NBR.b, 8*11 bytes) un nombre à 88 bits (NBR.a) plus un nombre à 1 bit (Code).

---

Attention, tu fais la supposition que un Byte fait huit bits (un octet), mais ça n'est pas toujours le cas, tu va trouver certaines architecture ou un byte vaut 11, voir 13 bits.

Alors je pense que Oneill va travailler sur une architecture ou ta supposition est correcte. Mais c'est un point à ne pas oubier non plus.

Bonjour,

Citation:

---

nombre généré sur 11 Bytes

---

Quelle est la représentation binaire ?
- 11 digits de 4 bits
- 11 caractères de 8 bits,
- entier long sur n bits,
- autre chose.

Bonjour,

Il y a une information qui ne me paraît pas claire dans l'énoncé : Est-ce que chaque byte de nbr.A peut prendre n'importe quelle valeur, ou les valeurs ne sont prises que dans un ensemble donné (caractère ASCII par exemple). Et ensuite comment est transmis le nombre d'une machine à l'autre ?

Edit : zut, j'aurai du lire moins en diagonale, Graffito pose presque la même question juste au dessus.

Je vais m'informer pour en savoir plus sur la taille en 'Bits' de ce nombre de 11 positions. Et ce que vous écrivez est très intéressant.
Car en effet, je parle de 11 chiffres de 0 à 9 !
Pour la compression, j'avais envisagé une RLE (sur les 88 bits)
avec décodage du type : si 1 alors la valeur suivant est répétée 3 fois
si 0 alors la valeur suivante est (répétée) 1 fois.
la lecture se fait par paire de bits


ex: 110010 donne 1110000
c'est extrèmement facile à coder... reste à vérifier l'efficacité.

Mais.. je fantasme encore sur l'idée d'une fonction génératrice ...

Citation:

---

Envoyé par Oneill

Car en effet, je parle de 11 chiffres de 0 à 9 !

---

Bjr,
Au temps ou la mémoire se comptait en kilooctets, les chiffres de 0 à 9 se codaient sur des quartets. (on le fait encore en microprogrammation).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

function ab = codage(a,b) ab = a*16+b; return   function [a,b]=decodage(ab) a=bitand(ab,240)/16 ; b=bitand(ab,15) ; return   function errors=check [a,b]=meshgrid(0:9,0:9) ; ab = codage(a,b) ; [a1,b1]=decodage(ab) ; errors = find(a~=a1 | b~=b1) ; return

---

donc tu peux libérer la moitié de l'espace occupé.
OL

Encore plus simplement tu peux transformer cette suite de 11 chiffres en un nombre de 11 chiffres, tu as pour cela besoin de ceil(log2(10^11)) = 37 bits. Tu rajoutes 1 bit pour le code, et il t'en reste 50 pour faire ce que tu veux :)

Citation:

---

Envoyé par sovitec

Encore plus simplement tu peux transformer cette suite de 11 chiffres en un nombre de 11 chiffres, tu as pour cela besoin de ceil(log2(10^11)) = 37 bits. Tu rajoutes 1 bit pour le code, et il t'en reste 50 pour faire ce que tu veux :)

---

:bravo: C'est ce que j'aime dans ce forum. Les idées tournent et font apparaitre des solutions limpides et simples.

OL