Bonjour la mifa,

Me Voici enfin dans la communauté, 

Chers ingénieurs, depuis 3 mois, je bosse sur l'algorithme me permettra de parcourir et traiter les arbres binaires, mais ... vrai vrai là je suis fatigué. J'ai tout fais en vain.Mais ma conscience me dit qu'il doit nécessairement exister une méthode ou une manière de le faire.

Voici mon problème mes gares:

Article 1 : Après lecture sur les documents traitant et expliquant les arbres binaires, j'aurais appris qu'il est possible de chercher un élément dans l'arbre juste connaissant sa position.

Article 2 : Le nombre d’élément au niveau(ou profondeur) p est 2^p

Mes limites : Comment faire pour afficher la position d'un élément avec p = 8388608 puisqu'on est appelé à traiter 2^8388608. Ce qui est impossible selon moi pour un ordinateur [dépassement de mémoire].

Mon algo consiste à déterminer la position k d'un élément E se trouvant à un  niveau ( ou profondeur) p dans un arbre A. Puis inversement à partir de ce nombre(position) k, retrouver le chemin qui même de la racine à l"élément E en appliquant la méthode suivant:

si k est impaire E se trouve à droite de son père sinon E est à gauche.

si k impaire , le père est en position(k-1)/2 sinon le père est en position k/2

Le résultat de cette opération est remonté à la même analyse.

Exemple de l'arbre est ci-dessous :

NB : Langage de votre choix

-
Edité par jesuiszero2 28 mai 2016 à 2:54:16

Salut,

Ton problème m'égare aussi, je ne comprends pas trop ce que tu dis.

Ça veut dire quoi chercher un élément en connaissant sa position (si on connaît sa position donc où il est, pourquoi le chercher !).

Qu'est ce que tu entends pas p = 2^p. Si c'est une égalité mathématique, elle est fausse ;-)
C'est quoi p ? Est-ce le même des deux côtés du signe "=" ? Est-ce une instruction qui est une étape dans ton algorithme ?
A priori pour un arbre binaire équilibré, le nombre d'élément dans l'arbre  stocké au niveau "p" doit être 2^p, c'est ça que tu veux dire ?

Pourquoi "8388608" ?

C'est faux que "2^8388608" est impossible à calculer, ça fait un nombre avec quelques millions de chiffres mais ça se calcul bien. Bien sur le résultat ne tient pas sur un "int" ou un "long" (pour java, regarde du côté des BigInteger ou BigDecimal).

Si 8388608 c'est la valeur que tu cherches dans ton arbre, alors ce n'est pas 2^8388608 opération qu'il faut, mais plutôt de l'ordre de log2(8388608).

Si ça fait vraiment trois mois que tu cherches et que ce n'est pas un exercice qu'on t'a donné, merci d'être plus précis dans ce qui te bloque.

-
Edité par macaque 25 mai 2016 à 21:44:19

Merci macaque de ton intervention aussi rapide et clair.

J'ai mélangé les pédales dans mes explications. Cela était dû par une journée fatiguée.

D'abord primo, ce n'est pas un exercice, c'est un projet perso que je doit valider (une sorte d'un défi dans mon entreprise).

Secondo, je vais essayer de m'expliquer encore aussi mieux  pour être plus clair.

Tertio, je suis débutant dans le traitement des arbres binaires et qu'après mes recherches et analyse des différentes méthodes de parcours des arbres, j'ai finalement opter la méthode ci-dessous pour mon problème.

Mon algo consiste à retrouver le numéro d'un élément de l'arbre à une grande profondeur(le défi ici est de réduire le numéro de cet élément à cette profondeur aussi petite que possible c'est à dire pas question de traiter les nombres à millions de chiffre) et d'appliquer la méthode de parité pour descendre jusqu'à la racine.

En analysant l'arbre ci-dessus et par construction, on peut  dire : il y a 2^n ascendants au degré n.

Par construction de l'arbre, à partir du degré 1 (racine), les pères ont un numéro pair et les mères un numéros impair.

par construction, le numéro de tout ascendant est 2p.

De façon général, si p est pair, le descendant porte le numero p/2, et si p est impair, le descendant porte le numero (p-1)/2

Dans mes recherches j'aurais appris qu'on peut retrouver le chemins d'un ascendants( élément de l'arbre) en connaissant sa position(son numero).

Exemple le degré 9 comporte 512 ascendants (2^9). Si on se positionne sur l'ascendant portant le numéro 612. on peut parcourir le chemin suivant:

Voici mes limites dans mon algo. 

Je doit traiter les données au degré n=8388608 donc j'ai affaire à 2^8388608 ascendants au degré 8388608 portant donc des numéros aussi grand. 

Question:

- Comment traiter ses données aussi grand facilement ( existe-t-il une astuce de transformer ces nombres en des valeurs plus petites) ?

- Existe-t-il des formules mathématiques plus simples pour la résolution ?

PS : Vos explications, astuces, formules mathématiques, algo me fairons plaisir.

Esperant vous avoir mieux expliquer mon problèmes, je suis à vous la communauté !!!! 

-
Edité par jesuiszero2 28 mai 2016 à 3:04:36

Voici le système dans mon entreprise qui est en cours de construction et dont le problème est à l'origine de ce poste:

Un algo qui trouverait la position(le numéro) d'un élément dans l'arbre au degré plus profond 8388608  (évidement l'arbre est numéroté comme expliqué dans mon second poste) , puis envoie ce numéro via sms (le nombre maxi de sms doit être de 160 caractères). Le système récepteur reçoit le message contenant donc le numéro (position) de l’élément et parcours son arbre de la racine au numéro réçu enfin d'effectuer d'autres actions.

Vous voyez qu'on ne peut pas envoyer un nombre de millions de chiffre( limite de sms s'impose).

J'ai regardé du côté des logb(x) mais rien.

J'avais essayé les astuces suivantes:

Le système sender, en constituant le numéro de l’élément en profondeur n=8388608 me donne le numéro de l’élément sous la forme : 2^n+2^m+2^k+2^t+....

par exemple prenons une petite profondeur pour comprendre:

soit n=6 notre degré de l'arbre binaire équilibré dont on connait le chemin de parcours suivant (de la racine à l'élément recherché) : mère-père-mère-mère-mère-père.

On a:

a0 = 1 (racine)

a1 :mère = 2a0 + 1

a2 :père = 2a1

a3 :mère = 2a2+ 1

a4 :mère = 2a3 + 1

a5 :mère = 2a4 + 1

a6 :père = 2a5 

On obtient a6 = 2^5 +2^3 + 2^2 + 2 = 110

donc l’élément porte le numéro 2^5 +2^3 + 2^2 + 2 = 110

La réussite de mon astuce serait donc de pouvoir traiter les 2^5 +2^3 + 2^2 + 2. soit en les transformant en une formule mathématique plus simple( c'est cette formule qui sera envoyé par gsm) soit en trouvant un moyen de rentre encore plus petit 2^5 +2^3 + 2^2 + 2.

Si l'astuce vérifiait pour n=6, cela pourrait être valable aussi pour n supérieur (8388608).

Bonjour,

En fait, c'est simple de retrouver le chemin si tu connais le numéro.

Ensuite, tu pars de la racine.

Tant que le nombre est > 1,

    Si ton nombre est impair, tu vas à droite, sinon tu vas à gauche.

    Tu le divises par 2.

Pour retrouver le nombre, tu pars d'une personne et du nombre 1,

Tant que tu n'est pas à la racine,

    Tu multiples ton nombre par 2.

    Si la personne est une femme, tu ajoutes 1.

    Tu descends dans l'arbre.

Je pense que je ne comprends toujours pas bien.

Tu dis "Un algo qui trouverait la position(le numéro) d'un élément dans l'arbre au degré plus profond 8388608".

Au degré le plus profond, il y a 2^8388608 élément, donc l'algo doit avoir le moyen de choisir lequel de ces éléments prendre.

Qu'elles sont les données en entrée de l'algo qui lui permettent le savoir lequel de ces éléments nous intéresse pour qu'il puisse en retourner le numéro ?

Sinon j'ai l'impression que tu essaie de réinventer un moyen de stocker les nombres sur moins de bits qu'on ne le fait actuellement...
Avec 160 octets, tu as au mieux 1280 bits d'informations (8*160), soit 2^1280 possibilités.

Si au départ tu as 2^8388608 valeurs qui sont équiprobables (que tu peux avoir besoin de transmettre n'importe laquelle avec la même probabilité que les autres), tu ne pourras pas indiquer laquelle de ces valeurs t'intéresse avec seulement 1280 bits. Il te faut au moins 8388608 bits d'informations.
Tu peux avoir des encodages ou algorithme de compression qui te permettent de réduire la taille pour des valeurs particulières, mais ça veut dire que ça fait grossir l'encodage pour d'autres valeurs.

(C'est rentable pour la taille moyenne si certaines valeurs on bcp plus de chance de se produire que d'autres, mais ça fait grossir la taille max dans tous les cas, et si les valeurs sont en plus équiprobables, ça fait aussi grossir la taille moyenne).

Tu ne peux pas faire de miracle. Si on a par exemple 8 valeurs équiprobables, de 0 à 7, la manière la plus efficace reste le stockage binaire sur 3 bits.
7 sera par exemple codé 111, c'est à dire 2^2 + 2^1 + 2^0 = 4 + 2 + 1 = 7

Comme les sms ne doivent pas supporter le binaire je suppose, le mieux que tu peux faire doit être d'encoder ton nombre binaire sur une base correspondant à de tous les caractères supportés par le SMS (donc encore moins que 2^2280 bits d'information).

Ici je pense que la seule chose que tu peux gagner pour envoyer les valeurs du degré "n", c'est de soustraire leur "numéro" par la plus petite du degré en question.

Si tu veux plus d'infos sur le sujet, renseigne toi sur la théorie de l'information.

-
Edité par macaque 28 mai 2016 à 11:56:21

Encore une fois merci macaque

Au fait, il s'agit de trouver le numéro d'un élément au degré n. Cela j'arrive à le prouver théoriquement. Si nous prenons même la demo de brubru777

on peut facilement trouver le numéro d'un élément de l'arbre au degré n.

Ici le seul souci est que ce nombre devient trop grand au degré n supérieur ( n > 2^32).

Or mon boulot consiste à permettre que le système A calcule la position de l'élément E de l'arbre connaissant le chemin(sous forme de 0=gauche,1=droite) pour atteindre E et ensuite envoie cette position au système B via GSM. Le système B doit être capable de retrouver le chemin en analysant bien sûr le numéro de l'element E reçu.

voilà, c'est tout mon système !!!! qui m'arrache les cheveux.

Avec des données plus petites de l’élément E dans l'arbre (degré n <= 23), cela est possible aussi théorique que pratique.

Pour les entiers arbitrairement grand, il y a la classe BigInteger.

Ou sinon, utilise Python. La taille des entiers n'y est pas limitée.

Oui BigInteger ou Python peut evidemment resoudre le problème de calcul. Le blème c'est que ce nombre qui, à priori contient des millions de chiffre doit être transiter via SMS au système B. Et c'est là que ça bloque(Le nombre de maxi de SMS 160)

Ah, ok. Du coup, je comprends mieux le message de macaque. Et il a parfaitement raison.

Wiii, vraiment ça m'arrache les cheveux !!!

Je ne sais pas quel formule matho faut-il. J'ai regarder du côté des logb(x) pour reduire la taille mais toujours bloqué.

Je vais approfondir la proposition de macaque qui dit ceci:"Ici je pense que la seule chose que tu peux gagner pour envoyer les valeurs du degré "n", c'est de soustraire leur "numéro" par la plus petite du degré en question."

Malheureusement, ça ne réduira tes données que d'un seul bit...

ou éventuellement un peu plus si tu transmets n en plus. Mais ne t'attend pas à des miracles.

-
Edité par brubru777 28 mai 2016 à 16:29:55

Pour ne pas m'evader dans les recherches, macaque tu peux m'expliquer mieux ta proposition qui dit : Ici je pense que la seule chose que tu peux gagner pour envoyer les valeurs du degré "n", c'est de soustraire leur "numéro" par la plus petite du degré en question

brubru777 , oui je sais que les miracles n'ont pas leur place en informatique qui est surtout fondé sur des raisonnement mathématiques. Les raisonnements mathématiques  étant infinis, je crois formellement que grace à vos propositions et suggestions nous pouvons en faire decouler un raisonnement valable à cet type de sujet. 

jesuiszero2 a écrit:

Pour ne pas m'evader dans les recherches, macaque tu peux m'expliquer mieux ta proposition qui dit : Ici je pense que la seule chose que tu peux gagner pour envoyer les valeurs du degré "n", c'est de soustraire leur "numéro" par la plus petite du degré en question

Comme l'a dit brubru, cette proposition n'était là que pour éviter de perdre 1 bit.

Je vais être plus clair : je pense qu'il est prouvé que ce que tu veux faire est impossible.

Au degré n, avec n = 8388608, tu as 2^n valeurs différentes qui vont de (2^n) à ( ( 2^(n+1) ) - 1 ).
Pour coder en binaire la plus grande valeur "( ( 2^(n+1) ) - 1 )", il faut n+1 bits, donc 8388609.

Ce que je disais, c'est donc que tu peux soustraire la plus petite valeur du dégré n, pour coder les positions des nombres par leur indice sur la ligne de degré n, ce qui revient à translater les valeurs (2^n) à ( ( 2^(n+1) ) - 1 ) vers les valeurs 0 à (2^n)-1.

La plus grande valeur à transmettre peut alors se coder en n bits, donc 8388608, on revient à la limite théorique dont je te parlais.

Je vais rajouter que pour économiser ce bit là, il faut que celui qui envoi et celui qui reçoit sachent à l'avance que la valeur transmise est au degré n. Si ce degré n'est pas statique et qu'il faut le transmettre, alors il faudra aussi compter les bits pour transmettre le degré !

La règle est simple : Pour coder le résultat d'un tirage aléatoire uniforme parmi 2^n valeurs, il te faut au minimum n bits en moyenne.

Si on reprend ton arbre. Pour atteindre le degré n depuis la racine, il faut faire n choix pour aller à gauche ou à droite.

Chaque choix étant binaire, tu peux le coder sur 1 bit.

Mais donc pour atteindre n = 8388608 tu dois faire n choix droite ou gauche. On retombe donc sur un codage de 8388608 bits.

-
Edité par macaque 28 mai 2016 à 18:43:27

je viens d'avoir une idée:

Si l'on enregistrait le numéro de l’élément E de l'arbre dans un BigInteger et effectue une division en 2^k dans le but de trouver un nombre N aussi petite de taille(nombre de chiffre). Lors de l'envoie ce nombre N associé avec la valeur K seront envoyé via GSM au système B. Puisque le système B saura qu'on est en puissance de 2,et  il suffirait que l'on fasse  2^k * N puis l'enregistrer dans un BigInteger. A ce niveau on peux appliquer l'analyse de parité sur ce nombre enfin de reconstruire le chemin menant à E.

Arithmétiquement on pourra posé :

soit M le numéro de l’élément E dans l'arbre.

N=M/(2^k)

Si telle méthode est valide, la question est de déterminer la valeur K qu'on pourra donc appliquer à M.

Votre avis avant que je trempe mes mains dans les codes. 

Cette méthode n'est pas valide. Elle va juste supprimer k bits d'information.

Ecoute ce que te dit macaque, ça t'évitera de perdre ton temps pour rien.

En fait "jesuiszero" plutôt que de vouloir absolument transmettre ce nombre en un seul SMS, tu aurais plus de chance en essayant de revoir le fonctionnement global.

A quoi correspond ce nombre que tu veux transmettre ? Est-il le fruit d'un calcul ?

Est-ce que le système B peut être capable de refaire ce calcul ?

Est-ce que le système B a nécessairement besoin de connaître ce chiffre et pourquoi ?

Est-ce qu'au lieu d'utiliser des SMS, tu pourrais utiliser de la data pour transmettre 1mo ?

Combien pèse ton arbre entier avec les données s'il y a autant d'élément dedans ? Pourquoi est-il partagé sur les deux systèmes ?

Est-ce que c'était juste un arbre théorique avec lequel tu espérais réduire la taille de donnée à envoyer ?

-
Edité par macaque 29 mai 2016 à 18:49:33

macaque a écrit:

En fait "jesuiszero" plutôt que de vouloir absolument transmettre ce nombre en un seul SMS, tu aurais plus de chance en essayant de revoir le fonctionnement global.

A quoi correspond ce nombre que tu veux transmettre ? Est-il le fruit d'un calcul ?

Est-ce que le système B peut être capable de refaire ce calcul ?

Est-ce que le système B a nécessairement besoin de connaître ce chiffre et pourquoi ?

Est-ce qu'au lieu d'utiliser des SMS, tu pourrais utiliser de la data pour transmettre 1mo ?

Combien pèse ton arbre entier avec les données s'il y a autant d'élément dedans ? Pourquoi est-il partagé sur les deux systèmes ?

Est-ce que c'était juste un arbre théorique avec lequel tu espérais réduire la taille de donnée à envoyer ?

-
Edité par macaque il y a environ 6 heures

A quoi correspond ce nombre que tu veux transmettre ? : Ce nombre doit correspondre à la position ou numéro d'un élément dans l'arbre binaire

Est-il le fruit d'un calcul ? : Surement Le système A doit fournir ce nombre

Est-ce que le système B peut être capable de refaire ce calcul ? : Non

Est-ce que le système B a nécessairement besoin de connaître ce chiffre et pourquoi ? : Oui,  le système a besoin de ce nombre pour recalculer le chemin de parcours

Est-ce qu'au lieu d'utiliser des SMS, tu pourrais utiliser de la data pour transmettre 1mo ? Il faut nécessairement passer par SMS

Combien pèse ton arbre entier avec les données s'il y a autant d'élément dedans ? l'arbre est variable , mini (2^8388608+1)+1 nœuds 

soit au degré minimal de 1Mo

Pourquoi est-il partagé sur les deux systèmes ? : Les deux systèmes sont indépendantes

Est-ce que c'était juste un arbre théorique avec lequel tu espérais réduire la taille de donnée à envoyer ? : Oui, les données à envoyer sont énormes donc nous avons trouvé une manière de les organiser dans un arbre, la réussite de ce projet serait donc que le système A calcule la position des données dans l'arbre, envoie cette position au Système B qui va à son tour parcourir l'arbre et retrouver l’élément de départ. Le système B régénère cet élément et active une action du central radioactive. 

NB : Nous avons porté le choix d'utiliser le GSM pour plusieurs raisons techniques et sécuritaires.

Ok, si je comprends bien l'arbre ne sert strictement à rien donc, il ne contient aucune donnée, c'est juste un artifice avec lequel vous souhaitez réduire la taille d'un entier ?

En gros c'est soit vous savez qu'il n'y a que certaines valeurs qui vont être envoyées,  dans ce cas là vous pouvez mettre ces valeurs dans un arbre qui est connu des deux côtés pour indiquer laquelle de ces valeurs est à prendre par sa position dans l'arbre. Et dans ce cas là, le nombre d'élément dans l'abre doit être beaucoup plus petit que la taille des valeurs à l'intérieur des éléments de l'arbre.

Mais si les valeurs qui peuvent être envoyées forme une plage continue d'entier, vous ne gagnez rien à les mettre dans un arbre imaginaire.

Imaginez que ce soit le cas. Dans ce cas là vous auriez trouver le moyen d'écrire n'importe quel nombre X écrit sur n bits dans un format Y qui comprends moins de n bits. Vous n'auriez alors plus qu'à faire pareil et écrire Y dans un format qui contient encore moins de bits, et ainsi de suite jusqu'à compresser votre information dans la taille voulue.
Vous auriez inventer un format de compression récursif sans perte "infini" plus fort que tout ce qui existe (gzip, rar, 7zip, etc), et même plus fort que les formats de compressions avec perte type mp3, mp4 ou jpg !

Plus besoin d'espace disque énorme, on peut représenter n'importe quelle séquence de bits en un nombre que l'on peut ensuite encoder dans un SMS de 160 caractères.

Plus sérieusement, il faut vous intéresser précisément aux valeurs que vous voulez transmettes. Si vraiment votre application doit pouvoir transmettre n'importe quelle valeur que l'on peut coder sur 8388608 bits en 1 seul SMS de 160 caractères, alors ce n'est juste pas possible.

Après si le résultat de votre calcul sur le système A ne peut atteindre qu'un certains nombres de valeurs (par exemple vous savez que ça sera forcément un multiple de 17 et de 89), alors il faut compter ce nombres de valeurs qui peuvent être atteintes pour connaître le nombre minimal de bits dont vous avez besoin pour transmettre ce résultat.

-
Edité par macaque 30 mai 2016 à 11:54:52

Merci bien macaque pour tes brillantes interventions.

Nous allons faire les dernières analyses de la faisabilité du système en tenant en compte toutes vos suggestions et explications puisque qu'il nous reste peu de temps dans ce projet.

Mais dites moi pouvez - vous être un peu plus clair sur ses phrases :

"Après si le résultat de votre calcul sur le système A ne peut atteindre qu'un certains nombres de valeurs (par exemple vous savez que ça sera forcément un multiple de 17 et de 89), alors il faut compter ce nombres de valeurs qui peuvent être atteintes pour connaître le nombre minimal de bits dont vous avez besoin pour transmettre ce résultat."

Nous sommes entrain de voir s'il est possible que le système A, au lien d'envoyer un nombre comme position de l’élément dans l'arbre,génère plutôt une fonction generatrice qui sera interpréter par le système B.

Pour illustrer sur un exemple simple.

Si le système A calcule la fonction f(x) = 8 * x, et que vous savez que les valeurs en entrée de A sont entre 0 et 10.

Vous savez alors que la valeur en sortie de A est entre 0 (8*0) et 80 (8*10).

Si on sait uniquement que la valeur est un entier entre 0 et 80 et qu'on ne sait pas que certaines valeurs sont impossibles (que par exemple A ne génèrera jamais une sortie qui vaut 2 ou 5), il faut alors au minimum 7 bits pour coder le résultat car vous avez 81 valeurs possibles, et que 2^6 < 81 <= 2^7.

Par contre si vous savez que les valeurs ne peuvent être que 0, 8, 16, 24, 32, 40, 48, 56, 64, 72 et 80, vous n'avez alors plus que 11 valeurs possibles. Il ne vous faut donc que de 4 bits (2^3 < 11 <= 2^4) pour transmettre l'information sur le résultat de du système A à B.

Et vous pouvez imaginez plusieurs solutions pour coder la valeur produite par A sur ces 4 bits.
Vous pouvez par exemple envoyer l'entrée de f(x) à B (donc envoyer un entier entre 0 et10) et le laisser refaire  le calcul.
Mais vous pouvez aussi utiliser une structure de données partagée des deux côtés qui permettra d'associer un code sur 4 bits à chacune des 11 valeurs possibles

Si la fonction A est très compliquée, vous ne pourrez sans doute pas lister exhaustivement toutes les valeurs possibles. Mais vous pourrez peut être restreindre l'ensemble de valeurs qui peuvent être atteintes.

Par exemple si vous ne savez pas que le résultat est multiple de 8, mais que vous savez qu'il est multiple de 4 et entre 0 et 80, vous avez 21 valeurs possibles.

Après il faut voir aussi si vous avez besoin d'une valeur exacte ou pas. Si ce n'est pas le cas quand vous faites par exemple un arrondi au millier sur des valeurs entières, vous diminuez le nombre de valeur possible par 1000, donc vous gagnez à peu près 10 bits.

-
Edité par macaque 30 mai 2016 à 15:30:20

Bien compris je fais implémenté et je te reviens

Malheureusement après un long moment de Brainstorming sur la proposition de macaque, nous n'avons pas pu démontrer mathématiquement. 

Nous nous sommes donc tournés vers une astuces que voici:

Au lieu que le système A généré  un nombre(comportant des millions de chiffres) comme position de l'élément E , ne serait-il pas possible de générer ce nombre au format de puissance de 2 ?

Exemple : si ce nombre vaut 12252022632...................   on aurait pu exprimer ce dernier en 2^k avec k< n. 

Qu'en pensez-vous ?

-
Edité par jesuiszero2 4 juin 2016 à 3:00:36

J'ai l'impression de me répéter, mais un nombre représenté sous forme binaire est déjà une décomposition du nombre en puissance de deux.

Je ne sais pas combien de temps vous avez déjà perdu sur le sujet, mais je vous conseille sincèrement d'arrêter et de passer à autre chose puisque vous semblez revenir en boucle sur la même problématique.

Si votre nombre comporte des millions de chiffres, il peut se décomposer en encore plus de puissance de deux.

Par exemple 511, qui ne fait que 3 chiffres, vous allez le décomposer comment en puissance de deux ?

Et bien il faut 9 bits, pour coder 2^0 + 2^1 + 2^2 + 2^3 + 2^4 + 2^5 + 2^6 + 2^7 + 2^8

Sinon il faut accepter de ne pas coder tous les chiffres et de perdre de la précision. Par exemple vous pouvez coder que les puissances 2^7, 2^8 et 2^9 ce qui vous permets avec 3 bits de coder les 8 (2^3) valeurs : 0, 128, 256, 384, 512, 640, 768 et 896 mais pas les autres valeurs.

Mais arrêter de chercher à coder toutes les valeurs possibles entre 0 et un nombre à plusieurs millions de chiffres en 160 octets, ce n'est juste pas possible !

Avec 160 octets, vous avez 160*8 = 1280 bits. Si on considère que toutes les valeurs d'octets peuvent être encodées dans le SMS, vous pouvez donc envoyer dans un SMS un choix portant sur 1 valeur parmi 2^1280 (ce qui donne de l'ordre de 385 chiffres en représentation décimale).
C'est déjà pas mal, mais on est loin de ce que vous voulez faire, et vous ne pourrez pas faire plus.

Si le résultat du calcul de votre système A est un choix parmi 2^8388608 valeurs potentielles, vous ne pouvez pas le coder dans 160 octets uniquement sans perte d'information. Il vous faut 8388608 bits donc 1048576 octets donc près de 7000 SMS.

Pour essayer d'exprimer les choses autrement, la bible au format texte compressé en .zip pèse de l'ordre de 1mo ce qui est du même ordre que le nombre d'octets nécessaires pour coder votre choix d'un nombre entre 1 et 2^8388608.
Si on pouvait encoder votre nombre dans un SMS, on pourrait aussi envoyer des textes littéraires contenant autant de mots que la bible dans un SMS.

Voilà, j'espère que vous aurez mieux compris le problème cette fois. Pour ma part, ce n'est pas dans mon habitude, mais je vais sans doute cesser de vous répondre également car c'est une perte de temps.

Bon courage pour la suite 

-
Edité par macaque 4 juin 2016 à 11:31:51