Version imprimable
Salut tout le monde,
Je souhaiterais savoir combien d'octets il me faut au minimum pour pouvoir coder 16 valeurs comprises entre 0 et 255. Je sais qu'il y a des pistes exploitables comme les "masques de bits" et tout (?), mais je sais pas à quel genre de fiabilité je dois m'attendre et surtout s'il y a un risque d'avoir des cas de blocage suivant les cas de figures.
Je pense à 4 octets, mais je suis peut-être à côté de la plaque.
Merci à vous.
Salut.
Un octet permet de représenter une valeur comprise entre 0 et 255 donc il t'en faudrait 16 logiquement.
Merci pour ta réponse,
Et effectivement, ce que tu écris, c'est ce qui vient en premier à l'esprit, mais quand je viens dans cette rubrique, heureusement rarement, c'est que je suis en recherche d'espoir :calim2:
Bonjour,
Pour moi avec 16 valeurs un demi-octet suffit pour les représenter.
Maintenant quel est le but au final ?
Tu as 2^n cas possible avec une base binaire,
Donc 16 cas, ça te donne 2^4, ce qui fait un demi-octet, en ayant par avance les 16 cas, et en faisant une table, par exemple :
[0][0][0][1] = 45
[0][0][1][0] = 147
... etc
par contre, un demi octet, ne te permet pas de compter "normalement", au delà de 15.
Salut et merci pour vos réponses à tout les deux.
Mais je crois qu'il y a un quiproquo.
En effet, mon objectif est de coder 16 nombres sur 8 octets, et chacun de ces nombres est compris entre 0 et 255. Sauf erreur de ma part, la notion de table présentée ne va pas dans ce sens, ou peut-être que je n'en ai pas compris le but ?
Enfin, si vous pouviez confirmer.
Encore merci.
Si les nombres sont quelconques entre 0 et 255, on ne peut pas trouver de codage qui dans tous les cas prennent moins de 16 octets.
Si certains nombres sont plus probables que d'autres, on pourra appliquer des techniques de compression. ainsi, dans la majorité des cas, on aura un codage plus court (moins de 16 octets), mais dans une minorité de cas, le codage necessitera plus de 16 octets.
Citation:
Envoyé par minnesota
un nombre compris entre 0 et 255 se code sur 1 octet.
Si les 16 nombres ne sont pas connu à l'avance, tu aura obligatoirement besoin de 16 octets, en toute logique... dès que tu utilisera un type de compression, tu aura besoin d'encore plus d'octet, et vu que tu as un nombre très petit de donnée, la compression va plutôt faire augmenté la taille de tes données, la compression deviens utile sur un nombre important de données.
Si les nombre sont connu à l'avance, avec une table de correspondance, ça te donne bien 8 octets :
[0000] = 10 [1001] = 180
[0001] = 20 [1010] = 190
[0010] = 40 [1011] = 200
[0011] = 60 [1100] = 210
[0100] = 80 [1101] = 220
[0101] = 100 [1110] = 230
[0110] = 120 [1111] = 240
[0111] = 140
[1000] = 160
[[0000][0100]][[1000][1110]]...
Merci beaucoup, c'est très clair maintenant.
Bon, aussi, dans l'état actuel des choses, je ne peux préjuger de la prédictibilité de ces nombres. On va faire avec alors. Et surtout dommage pour la compression, ça me semblait une bonne piste.
Grand merci à tous.