Discussion :

[jean-jacques varvenne]

hello à tous,

une question existencielle...

dans le fichier "ibase.h", il y a la déclaration des types de champs reconnus dans firebird, dont voici un extrait:

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
/*******************/
/* SQL definitions */
/*******************/
 
#define SQL_TEXT                           452
#define SQL_VARYING                        448
#define SQL_SHORT                          500
#define SQL_LONG                           496
#define SQL_FLOAT                          482
#define SQL_DOUBLE                         480
#define SQL_D_FLOAT                        530
#define SQL_TIMESTAMP                      510
#define SQL_BLOB                           520
#define SQL_ARRAY                          540
#define SQL_QUAD                           550
#define SQL_TYPE_TIME			   560
#define SQL_TYPE_DATE                      570
#define SQL_INT64			   580

les 2 types qui me troubles sont SQL_DOUBLE et SQL_D_FLOAT

SQL_DOUBLE est obtenu par exemple: create table foo( monchamp double precision);

la dessus OK, cela correspond au type SQL_DOUBLE mais alors, à quoi correspond le type SQL_D_FLOAT, comment créer un champ qui utilise ce type, quel est sa précision???

tout ce que j'ai trouvé jusqu'à présent et en gros: SQL_DOUBLE == SQL_D_FLOAT

alors la question est: pourquoi créer un type SQL_D_FLOAT ????

[qi130]

Peut-être pour des questions de compatibilité IB4 // IB6 // FB ?

[jean-jacques varvenne]

possible, mais j'ai des doutes la dessus

[qi130]

Bah, attendons le puits de savoir Barbibulle qui saura éclairer de sa sagesse infinie nos truculentes interrogations

[jean-jacques varvenne]

oui, mais je pense qu'il est en vacances 8)

faudra donc attendre un peux.

[Barbibulle]

Non je suis rentré mais je suis débordé

Comme vous l'avez deviné D_FLOAT = DOUBLE d'un point de vue précision.
Donc codage sur 64 bits.

Ensuite (il me semble) pour ce qui est de la différence c'est surtout la façon de coder ces 64 bits qui est différente.
le D_FLOAT est il me semble réservé au monde VAX / VMS
le DOUBLE PRECISION respecte quand a lui la norme IEEE double précision.

D'ailleur je crois qu'il y a une option de précompilation pour préciser à gpre que le codage des double precision doit se faire comme les d_float et cette option n'est exploitable que pour les programmes tournant sur VAX / VMS.

[jean-jacques varvenne]

merci Barbibulle pour ces précisions.

j'en déduit donc que la commande sql correspondante et donc du genre: create table foo( monchamp double precision);

et que cela produit donc un type interne "SQL_D_FLOAT" ou "SQL_DOUBLE" en fonction de la compilation et du système?

et courage pour le débordement, après la pluie, vient le beau temps 8)

[Barbibulle]

oui dans IB/FB la déclaration du champs est identique.
Par contre c'est pour le reste qu'il y a une différence. L'application cliente, si celle ci est sous VAX / VMS les Double Float sont codés différemment que sous IB/FB, celà necessite donc une translation. Je suppose donc que sous ces systemes il faut que l'appli cliente utilise ce fameux d_float et précompile avec l'option d_float afin que les échanges se fasses bien (je suppose que dans la base le double précision reste à la norme IEEE sinon je ne vois pas l'interret. Et celà impliquerait qu'une interrogation d'un programme sous un autre OS ne pourait lire directement ce double précision car il ne serait pas à la norme IEEE.).
Donc à mon avis c'est juste un type pour premettre de traduire le format double_float des VAX/VMS au format IEEE.

Mais j'avoue n'avoir jamais eut à l'utiliser.

[jean-jacques varvenne]

merci Barbibulle pour ces précisions.

en fait, je suis occupé à "m'amuser" avec du Python et le module kinterbasedb.

ce module transmet une structure de l'ensemble de données en cours, mais l'auteur effectue une translation vers le type python, dans ce cas, il m'était impossible d'afficher les types des champs produits par la requête.

j'ai donc "patché" ce module pour qu'il "affiche" les types sql: integer, char, varchar, etc... et c'est à ce moment là que je suis "tombé" sur le D_FLOAT qui était décodé en même temps que le DOUBLE, c'est cela qui m'a troublé!

en effet, je ne savais pas "prédire" le type sql correspondant.

je vais encore faire quelques tests la dessus avec les infos que tu m'as données, lorsque cela fonctionnera, je reviendrais ici t'en faire part, histoire de complèter nos infos.

je vais donc marquer ce post comme "résolu", mais il n'est pas fermé.

encore merci des infos.

[Barbibulle]

Voici des éléments de précisions pour comprendre pourquoi il existe le type D_FLOAT sur les machines VAX.

Code de l'equivallent du double précision sous VAX (D_FLOAT)

Codage utilisé par défaut par Firebird/interbase (norme IEEE) pour les DOUBLE PRECISION

On voit bien que la signification des bits n'est pas la même (du moins pas au même emplacement, Et donc sous VAX pour pouvoir envoyer des double precision il faut bien lui préciser que ce n'est pas au format habituel (IEEE) mais au format VAX, d'ou l'utilisation du type D_FLOAT.

Enfin c'est comme ça que je le comprend. Ce qui est certain c'est que c'est liè à cette différence d'encodage des type FLOAT entre le monde VAX et la norme IEEE qui est la plus répendue.

[jean-jacques varvenne]

en fait le plus important pour moi et de savoir que la requête qui "donne" un d_float ou un double soit "double precision"

et que la conversion dans un sens ou dans l'autre donne toujours le même résultat en terme de type sql

donc pour résumer:

Code :

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

1
2
SQL_DOUBLE <==> DOUBLE PRECISION
SQL_D_FLOAT <==> DOUBLE PRECISION

ce qui semble au vu des documents être vrai.

donc dans la pratique, lorsque je reçoi le code 480 ou 530, je le traduit par "double precision", le reste n'étant pas de mon ressort.

merci Barbibulle pour ces infos et ces recherches.

[Barbibulle]

Oui tout a fait, mais le type 480 (D_FLOAT) a moins de travailler sur VAX, vous ne le rencontrerez jamais.

J'ai trouvé ce code qui confirme l'equivalence des deux types :
http://www.koders.com/c++/fid79B96A9...A7258A618.aspx (recherchez sql_d_float et vous verrez qu'a chaque fois il est associé avec le SQL_DOUBLE).

[jean-jacques varvenne]

oui, c'est ce que j'ai remarqué lorsque j'ai "patcher" kinterbasdb, et c'est cela qui ma troublé, merci pour les infos, cela à lever un doute sur ce type.