Version imprimable
Salut!
Comme l'écrivait très justement Georg Polya, pour résoudre un problème, il faut d'abord le comprendre, c'est-à-dire, entre autres connaître les données, ce qui ne semble pas être le cas ici. Pour le moment, ton problème semble donc insoluble.Citation:
je n'ai aucune idée sur les valeurs que je vais recevoir
Jean-Marc Blanc
:calim2:Citation:
Envoyé par DjÔsh Nash
y'a kke chose que je comprend pas..
Dans ton premier post, tu dis que tu dois faire une IHM pour afficher des données.. Là tu nous dis que tu sais pas ce que sont tes données...
Soit tu as un gros problème de conception, soit un gros problème de communication...
Non c'est juste que je n'ai pas toutes les données nécessaires à la bonne réalisation de ma partie du projet. Moi je me charge seulement de l'IHM. je n'ai pas une connaissance globale sur la totalité du projet. Du coup ce n'est pas très transparent.
Comme je l'ai dit, je connais certaines généralités sur les données, comme le fait que ça soit des données standards qui vont être émises par radio, réceptionnées, traitées par un MODEM, stockées en RAM sur 32 bits. Mais je ne connais pas, par exemple, la puissance des différents tons lors de l'émission. Et j'avoue ne pas avoir les connaissances nécessaires en télécom pour me pencher sur tout cela. Je ne sais pas si la puissance mesurée des différents tons à la réception peut varier en fonction de différents paramètres, comme la distance, les obstacles ect ect...Il m'est donc impossible de donner valeur autour de laquelle on va varier ect ect...
Si ce sont des ondes radio, il doit bien y avoir un domaine de fréquences..
De l'odre du kHz, Mhz, Ghz..
Et une précision associée..
Tu ne reçois pas la télé en Ghz avec une précision du Hz...
C'est ce que je veux dire plus haut...
Même si ta mesure est en Ghz, donc 10^9 Hz, tu as un certain domaine (de x à y Ghz) avec une certaine précision.
Tu ne remplis donc pas aléatoirement tes 32 bits, même si les valeurs en elles-mêmes sont 32 bits..
Tu as donc les conditions pour diminuer facilement le nombre de bits associé à chaque valeur..
Selon le type du signal, tu peux aussi utiliser une échelle logarithmique ou qqchose du style.
Cf. ne pas utiliser une échelle linéaire mais logarithmique ou exponentielle afin de pouvoir y privilégier les grands chiffres ou les petits chiffres et/ou en utilisant une autre fonction ou une table de conversion 32 -> 16 bits plus adaptées)
@+
Yannoo
Sauf si je me trompe, je crois qu'il y a un flou dans ta conception du problème.
Ton objectif : passé de x bits/s à y bits/s, y<x.
Si tu n'as aucun pouvoir sur ton média, tu ne pourras pas l'influencer.
Donc si ta condition, c'est de transmettre x bits/s sur celui-ci, tu ne pourra pas en faire transité y bits/s, avec y<x. Autrement dit, si tu n'as pas d'influence sur le débit, tu ne pourras pas aller plus vite en te focalisant sur ton flux d'octet qui y transite. Autrement dit, les algos de compression à ce très bas niveau sont déjà au top (en tout cas, je pense que tu perds ton temps à investir ton temps dans ce problème).
Ton problème comme je le comprends, c'est que tu veux réduire la quantité d'information à transmettre, sans même parlé de média (j'entends par média le RS232, DSL, fibre optique, ...). Donc pour pouvoir réduire cette information, tu souhaite la compresser.
Et j'ai l'impression que ce que tu n'as pas assimilé (ou alors j'ai mal compris), c'est que la manière dont est transmise cette information n'est pas importante pour la compresser. Peu importe si tu reçois un flux d'octet aléatoire. Ton modem transmets les bits que tu lui demandes de transmettre à une vitesse fixe, et tu ne le changeras pas. Vu la manière dont tu en parles, c'est bien trop bas niveau pour que tu arrives à faire quoique ce soit en si peu de temps.
Non, toi ce que tu veux, c'est réduire l'information à transmettre au modem (et du coup réduire le temps de transmission de cette information).
Tout ce beau discours pour te faire comprendre un truc. Lorsque que l'on te demande "quelles sont les données que tu transmets ?", la réponse n'est pas "un flux d'octets aléatoires définis par les caractéristiques de mon média", la réponse c'est "de l'information". (information = donnée + sens). Et donc la question qui aurais-dû t'être posé, c'est "quelle est l'information que tu souhaites transmettre ?".
Ainsi, je repose la question, après un bon nombre de post qui te demande la même chose, que transmets-tu ?
Des données de positions (compris entre tel et tel intervalle), des données comptables ? Du texte ASCII, de l'UTF ? (déjà compressé ? comment ?) ? Les données d'un capteur quelconques ? Bref, d'où viennent tes données et quelles sont leurs caractéristiques ?
Après ces questions, la suivante est : "Puis-je me permettre de perdre des données (redondance, précision, sensibilité, ....)".
Si non, alors tournes-toi vers LZW ou ses dérivés (compression sans perte).
Si oui, alors tu dois répondre aux premières questions, car c'est à mes yeux un prérequis à toutes formes de compression avec pertes.
En espérant t'avoir un peu éclairé.
ps: on est plus du tout dans une IHM. Mais bon...