tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : [Tsp-devel] Recueil de besoin.


From: TSP
Subject: RE : [Tsp-devel] Recueil de besoin.
Date: Tue, 31 Jan 2006 10:32:13 +0100

En fait sur un double tu as 51 bits de mantisse, donc tu peux stocker un
entier compris entre 0 et 2^51.
L'idée je crois d'Eric, est de distribuer des entiers mais stockés à
l'interieur d'un double tant que TSP ne gere pas autre chose.
Le sotckage se fait non pas en tant que pointeur, mais bien en tant que
valeur (mydouble = (double)myint)
Donc un entier I/U32 (2^32) rentre très bien dans ce cas. C'est quand on
depasse les 51 bits que tu auras une perte de LSB.
Donc ton code doit être tout simple.
        uint64_t myval; /* Type POSIX */
        myval = (uint64_t)mysample->value; /* FIXME, later could be another
thing than double */
Ensuite c'est ce myval que tu formates comme tu veux (hexa, bin, octal, gout
fraise, ....)

Y++

-----Original Message-----
From: Euskadi [mailto:address@hidden
Sent: Monday, January 30, 2006 9:33 PM
To: Erk; TSP Devel
Subject: Re: [Tsp-devel] Recueil de besoin.


On Mon, 30 Jan 2006 00:53:17 +0100, Erk <address@hidden> wrote:

> 2006/1/29, Euskadi <address@hidden>:
>> On Wed, 25 Jan 2006 21:29:06 +0100, Erk <address@hidden> wrote:
>>
>> > Mon ordre de priorité serait:
>> >
>> > 1) hexadecimal    (par paquet de 1/2/4/8 octets) genre
>> >            FF AA BB 34 11 22 22 66
>> >    ou    FFAA BB34 1122 2266
>> >    ou    FFAABB34 11222266
>>
>> Si je comprends bien, la première ligne correspond aux paquets d'1 
>> octet,
>> la deuxième aux paquets de 2, la troisième aux paquets de 4 octets. Et 
>> il manque la ligne avec le paquet de 8 octets.
>
> Oui.
>
>> Pour passer du real-double à la valeur hexadecimale, je ne regarde que 
>> les
>> 32 bits en ne tenant pas compte de la mantisse, de l'exposant, du signe 
>> ??
>> C'est ça ?
>
> Non je pense que pour l'instant on doit convertir la valeur double en
> entier puis "interpréter" cet entier comme 32 bits non signés
> à afficher, en hexa/dec/octal/bin  etc...
> Effectivement je n'ai pas pensé à préciser ce que je pensais.

Donc, on perd la partie décimale. Correct ?

Au fait, un double fait 64 bits....
DLB_MAX vaut 1.8e+308, je le convertis en quoi ?

>
> Je pense que tant qu'on a pas le multi-type les affichages
> "hexa/bin/dex etc..." sous entende une conversion en entier
> (non signé)  avant affichage.
>
> C'est un peu embêtant de faire ça (car c'est temporaire)
> mais c'est ce qui semble le plus "utile" à l'heure actuelle,
> mais tu as peut-être un avis différent?

C'est le besoin qui dicte le tout.
Pour avoir été confronté au problème récemment, les deux façons
sont envisageables :
        - on regarde les 64 bits sans aucune transformation
        - ou alors on transforme, et on regarde les bits après coup.
Qu'en pensent les utilisateurs ? et les autres tsp-men ?

Pas de pb pour implémenter les deux.

>
> Sinon pour être "complet" il faudrait ajouter de quel type on
> considère la conversion (int8, uint8, int16, ... uint64, int64, float,
> double, quad)
> même si pour l'instant le type "TSP" sera toujours "double" on peut
> ainsi le "convertir" comme un int.

Là, je comprens à moitié. Faut qu'on en reparle.

B'Soir.

_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel




_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel

---------------------------------------------------------

CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT 
ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.

SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, 
MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER 
ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, 
VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE 
COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.



This email is for information only and will not bind EADS Astrium SAS in any 
contract or obligation, nor its subsidiaries.

If you have received it in error, please notify the sender by return email. If 
you are not the addressee of this email, you must not use, keep, disseminate, 
copy, print or otherwise deal with it.

---------------------------------------------------------




reply via email to

[Prev in Thread] Current Thread [Next in Thread]