Discussion :

[Arnaud F.]

Bonjour à toutes et à tous,

dans le cadre d'un projet (universitaire) de compression, je dois implémenter un algorithme qui permet de compresser la chaîne de caractères donnée.

Pour ça, je dois transformer des nombres en réels en binaire ( selon la norme IEEE je pense, car non spécifié ). Y a t'il une fonction dans l'API toute faite ou faut-il coder cela soit même?



[edit]

On note ensuite le mot binaire formé par les mk chiffres après la virgule de l'écriture en base 2 du réel ak

[Diablo_22]

Pour une conversion en utilisant la norme IEEE, on a les méthodes suivantes:
- intBitsToFloat(int)
- floatToIntBits(float value)

SOURCE SUN

[Arnaud F.]

Perplexe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.out.println(Double.doubleToLongBits(3.5));

me renvoi :

4615063718147915776

alors que j'attend :

01000000011000000000000000000000

J'utilise mal la chose?
[edit] Je bosse avec des double et non Double, mais je ne sais pas comment faire pour autant

[tulipebleu]

En fait, la methode Double.doubleToLongBits te donne un long.
Je pense que si tu veux l'afficher, il faut encore decortiquer en utilisant les &. Parce que sinon, cette suite de bit sera converti en nombre, puis en chaine et donc te donne un nombre.

Pourquoi ne pas utiliser directement l'opérateur & avec un double ?
Parce que c'est interdit avec les "double" et les "float"

[Arnaud F.]

Tu pourrai donner un exemple ?

J'ai du mal à te suivre

[®om]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String binaire = Long.toBinaryString(Double.doubleToLongBits(3.5))

[Arnaud F.]

beaucoup Rom, seulement le résultat que j'obtiens n'est pas cohérent car ta méthode me renvoi (pour 2.5) :

100000000000100000000000000000000000000000000000000000000000000

tandis que celle d'un convertisseur me renvoi :

01000000001000000000000000000000

Je sais pas lequel est correcte...

D'où peut venir cette divergence?

[tulipebleu]

Pour être franc, je ne sais pas lequel est le bon.
Mais si tu ajoutes au début de la 1ere suite de 1 et de 0 un 0, tu as exactement 64 catactères, donc 64 bits. pour le 2eme nombre, tu as 32 caractères, donc un nombre en 32 bit.

Comme les doubles font 64 caractères, je pense que le 1er est plus juste.

Cependant, il y a peut être un problème de little endian et de big endian.
En informatique, pour les nombres sur 32 bits (donc sur 4 octets), il peut y avoir la forme big endian (poids fort devant:AABB), ou la forme little endian (point faible devant:BBAA), je pense qu'il doit y avoir un système semblable pour le 64 bits, mais je ne le connais pas. Pour avoir plus d'info, je te conseil google.

Reste a savoir le format (big endian/little endian) que tu soihaites afficher.

[®om]

beaucoup Rom, seulement le résultat que j'obtiens n'est pas cohérent car ta méthode me renvoi (pour 2.5) :

tandis que celle d'un convertisseur me renvoi :


Je sais pas lequel est correcte...

D'où peut venir cette divergence?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String binaire = Integer.toBinaryString(Float.floatToIntBits(3.5f))

EDIT: il faut juste rajouter des 0 devant pour qu'il y ait 64 ou 32 bits selon le cas, le toBinaryString n'ajoute pas de 0 non significatifs...

[Arnaud F.]

Yes, beaucoup Rom, t'es un génie

Mais reste une question, l'algo stipule que je dois prendre un certains nombres de chiffres après la virgule... Et la, je vois pas trop de virgules, enfin comment définir où elle est...

J'suis un peu perdu ! Les réels peuvent ils aussi s'écrirent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

0101 , 1010 1010 0011 0011 1001

?

[®om]

J'suis un peu perdu ! Les réels peuvent ils aussi s'écrirent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

0101 , 1010 1010 0011 0011 1001

?

Ça c'est en virgule fixe, qui n'est jamais codée dans les languages de programmation (si on en a besoin, on utilise des int, et on divise à l'affichage).

Ce qui est utilisée, c'est la virgule flottante, séparée en 3 parties:
BIT DE SIGNE : 1 pour -, 0 pour +
EXPOSANT : exposant biaisé
MANTISSE : chiffres significatifs, avec un 1 implicite

En simplifiant, un nombre c'est signe * mantisse * 2^exposant.

La répartition est la suivante :
double (64 bits) : 1 | 11 | 53
float (32 bits) : 1 | 8 | 23

L'exposant est biaisé, pour obtenir l'exposant "lisible" il faut retirer 2^k-1 (si je me souviens bien) avec k = 8 pour les floats et 11 pour les doubles (à vérifier dans la norme IEEE).

La mantisse contient un 1 implicite en première position, donc il représente respectivement 54 ou 24 chiffres significatifs.

Ça c'est pour la majorité des chiffres, après il y a des codages spéciaux (pour 0 par exemple, car c'est le seul chiffre où le 1 implicite ne peut pas marcher), pour NaN, pour +infini, pour -infini, et il y a aussi les nombres dénormalisés pour les nombres très petits (pas de 1 implicite et exposant prédéfini).

Bon courage

[Arnaud F.]

Merci pour toutes ces explications

Néanmoins, je vais attendre avant de coder tout ça tête baissée, je vais déjà tenter de comprendre cet algo car il m'a l'air bien bizzare sur certains points, notamment sur l'écriture exacte attendue

Je ne sais pas s'il faut des binaires à virgules ou s'il faut les transformer sans, bref, vais déjà tenter de dérouler manuellement l'algo...

encore