Discussion :

[Letinono]

Bonjour à tous,

je récupère une trame d'une capacimètre sur un bus GPIB qui encode les données d'un nombre à virgule flottante à la norme IEEE754. Delphi est censé gérer cette norme.

Le problème est que je ne parviens pas à récupérer la valeur flottante de mon nombre. Je vous mets un petit code d'exemple pour vous montrer l'algo que j'emploie.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
procedure TForm1.Button1Click(Sender: TObject);
var
  dataA : array [0..7] of char;
  Y : ^double;
  i:integer;
begin
  dataA:=
    char($BF)+
    char($F8)+
    char($00)+
    char($00)+
    char($00)+
    char($00)+
    char($00)+
    char($00);
  Y:=@dataA;
  showmessage(floattostr(Y^));
end;

Normalement, si je ne me trompe pas ce code devrait me renvoyer la valeur suivant : -1.5, or il me renvoi 3.14616062615247E-319.

Voila si quelqu'un à déjà eu ce genre de soucis

Merci.

[ShaiLeTroll]

Ce n'est qu'un Double, voir ce sujet "Problème virgule flotante"

pourquoi faire si compliqué ? les pointeurs sont inutiles ... tu aurais fait un cast ça suffisait

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
procedure TModuleImportPHPAPITestForm.Button4Click(Sender: TObject);
var
  dataA : array [0..7] of char;
begin
  dataA:=
    char($00)+
    char($00)+
    char($00)+
    char($00)+
    char($00)+
    char($00)+
    char($F8)+
    char($BF);
    showmessage(floattostr(Double(dataA)));
end;

ou encore, une union pour éviter un cast trop "brutal" que l'on risque d'oublier le pourquoi du comment ... alors que l'union fortement typé aide à se souvenir ... même si le cast c'est marrant

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
type
  TUDouble = record // Union Double 
    case Boolean of
      True:
      (
        Value: Double;
      );
      False:
      (
      Data: array [0..7] of Byte; // Ou Char ...
      );
  end;
 
procedure TForm1.Button1Click(Sender: TObject);
var
  DoubleData : TUDouble;
begin
    DoubleData.Data[0]:=$BF;
  DoubleData.Data[1]:=$F8;
  DoubleData.Data[2]:=$00;
  DoubleData.Data[3]:=$00;
  DoubleData.Data[4]:=$00;
  DoubleData.Data[5]:=$00;
  DoubleData.Data[6]:=$00;
  DoubleData.Data[7]:=$00;
 
  ShowMessage(FloatToStr(DoubleData.Value));
 
  DoubleData.Data[0]:=$00;
  DoubleData.Data[1]:=$00;
  DoubleData.Data[2]:=$00;
  DoubleData.Data[3]:=$00;
  DoubleData.Data[4]:=$00;
  DoubleData.Data[5]:=$00;
  DoubleData.Data[6]:=$F8;
  DoubleData.Data[7]:=$BF;
 
  ShowMessage(FloatToStr(DoubleData.Value));
end;

Je n'ai pas le temps de tester, mais en mémoire, les nombres sont écrit à l'envers de nous, car en fait nous écrivont les chiffres dans le mauvais sens du fait de la différence latin et arabe ... nous écrions mille en 1000 mais en informatique, le sens a été remis dans le bon sens que l'on aurait du prendre donc 0001 ... cela commence par le octet le plus faible vers le plus fort ... normal, le registre 0 contient le faible, le registre 7 contient le fort, c'est purement logique lorsque l'on pense que les rétenus dans les opérations arithétique sont repoussé de bit en bit ... bon c'est pas clair, mais c'est pas grave ...

en gros -1,5 (dec) = 1011 1111 1111 1000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

en fait en mémoire, tu as donc 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 1111 1111 1101, c'est con non, ça n'aide pas à comprendre ...

[Letinono]

J'ai bien compris que les données sont mises à l'envers.

Comment on aurait pu le savoir???????

Merci pour ton aide.

[Aka Guymelef]

Comment on aurait pu le savoir???????

En fait moi-même je ne le savais pas jusqu'à ce que ShaiLeTroll ne le dise mais en fait en y repensant ça devient très logique. En effet souvenez vous des temps anciens (bénits ?) où pour cheater sur les jeux il fallait éditer les fichiers de sauvegarde et remplacer les valeurs hexas par d'autres. Et bien si vous vous souvenez les valeurs numériques transformées en héxa devaient être "retournées" avant d'être écrites dans le fichier. Tout se tient

[Franck SORIANO]

Comment on aurait pu le savoir???????

Il faut connaitre un peu l'architecture des ordinateurs.

La convention little-endian (poid faible en premier, tel que décrit par ShaiLeTroll ) est utilisée sur les architectures Intel (donc les PC et compatibles).

En revanche, sur d'autres architectures c'est la convention big-endian (poid fort en premier) qui est utilisée. C'est notamment le cas des Motorola (donc bon nombre de stations HP).

[Letinono]

Merci pour ces précisions Franck. Je vais essayer d'en chercher un peu plus à ce sujet.

[droggo]

Gao,

J'ai bien compris que les données sont mises à l'envers.

Comment on aurait pu le savoir???????

Merci pour ton aide.

En lisant la doc de ton appareil.

[ShaiLeTroll]

J'ai bien compris que les données sont mises à l'envers.

Comment on aurait pu le savoir???????

Merci pour ton aide.

Simple, j'aurais pu le deviner durant les cours d'assembleur à l'école, mais on a jamais exploité plus que AL ou AH, ... en fait, c'est un jour, en écrivant du binaire dans un fichier que j'ai compris (d'ailleurs cela me fut utile pour modifier mes sauvegarde de Baldur's Gate avec Ultra Edit comme le faisait remarquer Aka Guymelef) ... je n'ai découvert qu'il y a peu de temps qu'en fait c'était juste la convention little-endian (lorsque j'étudiais les charset et les format de dates) cité par Franck SORIANO, on sait parfois les choses sans pouvoir les nommer

pour toi, en faisant l'inverse, en mettant 1.5 dans un Double, puis de faire afficher le tableau, tu aurais vu l'inversion ... tu aurais ainsi résolu en expérimentant la réciproque ...

[sapin]

Gao,

En lisant la doc de ton appareil.

Je pense que son problème ne venait pas son appareil, mais -comme dit ci dessus- de l'architecture du processeur.

[droggo]

Gao,

Je pense que son problème ne venait pas son appareil, mais -comme dit ci dessus- de l'architecture du processeur.

La doc de l'appareil précise forcément le format des données envoyées, donc l'ordre des octets arrivant sur la liaison.

Je n'ai jamais eu à utiliser un appareil dont la doc ne précise pas tout ce qui est nécessaire pour l'interfacer à un programme.

[Letinono]

Gao,

La doc de l'appareil précise forcément le format des données envoyées, donc l'ordre des octets arrivant sur la liaison.

Je n'ai jamais eu à utiliser un appareil dont la doc ne précise pas tout ce qui est nécessaire pour l'interfacer à un programme.

Ca n'explique pas pour autant que l'architecture de mon processeur à besoin d'avoir l'octet de poids faible en premier pour caster la donnée en double.

Si tu le savais c'est très bien, je ne le savais pas.

Merci pour vos informations.

[Nono40]

Je n'ai jamais eu à utiliser un appareil dont la doc ne précise pas tout ce qui est nécessaire pour l'interfacer à un programme.

Tu as de la chance. Il arrive d'avoir à espionner des trames, lire des fichiers avec un éditeur hexa, etc. Juste pour savoir ce qu'il faut pour communiquer.

Quant au format interne permettant un cast facile tout le monde ne le sais pas loin de là. Quant on est sorti de l'assembleur c'est naturel, quand on part de Delphi pour c'est loin d'être évident.