[gull] déserialiser une valeur double (ieee 754) avec be64toh

[Daniel Cordey]

On Thu, 1 Mar 2012 18:44:12 +0100 - Philippe Strauss
<philippe at strauss-acoustics.ch> wrote:

> hmm cela doit être une chierie avec un cast automatique float/double
> <-> int pour par ces macros de byte swapping.

Ah oui... :-) J'ai remarque qu'avec les annees le compilateur C++
devenait de plus en plus ch... Il effectue des casting alors que l'on
veut justement l'eviter. Bien sur, on peut derive une classe a partir
d'un type de base et descactiver la "coercion", mais c'est un peu lourd.

> entre temps j'ai failli me perdre dans un dédale de références de
> macros de .h en .h sous osx, pffft, épuisant.

Tout a fait, je compatis :-) le casting se fait peut-eter de maniere
"aveugle" dans les macros. Les macros sont souvent mal ecrites et ne
"protege" pas bien les arguments.

En plus, osx c'est du BSD avec la sauce A*, le pire etant un
constructeur ayant base son code sur SYSV, incluant les goodies BSD, le
tout "emballe" dans la sauce du constructeur qui a encore rajoute les
couches POSIX, OSF etc. Jouissif !

##################

Pendant qu'on-y-est... je tombe sur un truc Python/Numpy qui m'enerve...

a = array([101, 210, 3, 4, 5])
b = a.astype(numpy.float32) / pow(10, 2)
c = b.round(decimals = 2)

print (c)

---> [ 1.01000023  2.10000038 3. 4. 5.]

Perso, je dirais que c'est un bug de la methode round().

Que ce probleme d'arrondi existe juste apres la division, je veux bien
(et c'est assez normal), mais round() devrait justement me permettre de
me debarasser des decimales indesirees; or, comme on peut le voir, ce
n'est pas le cas ! Je dirais meme, a quoi 'round' peut-il bien servir
s'il ne fait pas son travail ?

Quelqu'un a-t-il deja experimente ce probleme ?

dc