2013-09-23 25 views
6

galleggiante Ho questo frammento di codice con uno strano risultato(279.1 vs 279.6 ... ...):Perl strano comportamento sulla estrazione del valore

$ perl -e "print unpack('f>', pack ('f>', 279.117156982422));" 
279.617156982422 

Mentre questo funziona

$ perl -e "print unpack('f>', pack ('f>', 279.117256982422));" 
279.117248535156 

E quelli così

$ perl -e "print unpack('f<', pack ('f<', 279.117156982422));" 
279.11715698242 

$ perl -e "print unpack('f', pack ('f', 279.117156982422));" 
279.117156982422 

Cosa c'è di sbagliato? È un bug nel disimballaggio dei valori in virgola mobile endian non nativi?

Nota Perl è la versione 5.14.2 sotto Cygwin su un PC.

+1

I primi due casi vengono eseguiti con versioni diverse di Perl o sistemi operativi diversi? –

+0

Qual è il risultato di 'pack' nel primo caso (intendo, quali sono i bytecode)? – raina77ow

+0

Riproducibile qui con 5.14.2 (su Cygwin su Win7x64). Curioso. Potresti aver trovato un bug. Si noti che 'print unpack ('H8', pack ('f>', 279.117156982422))' per ottenere i bit restituisce '438b8eff', che è il modello di bit corretto secondo [questo sito] (http: // babbage. cs.qc.cuny.edu/IEEE-754.old/Decimal.html) –

risposta

1

Questo è un problema GCC.

cpan -t Acme :: Studio :: SREZIC passa OK sui miei sistemi a 32 bit in cui il binario Perl è compilato con GCC 4.5.4 o 4.6.3 o 4.6.4 e non passa su sistemi in cui il binario Perl è compilato con GCC 4.7.3 o 4.8.3

1

Sicuramente un bug nel disimballaggio di Perl. Ha difficoltà a gestire i float nella forma binaria xxxxyyFF almeno in una piattaforma a 32 bit, dove 80 <= yy <= BF. Il risultato compresso diventerà xxxxzzFF, dove zz = yy + 40 (tutto in esadecimale). E questo è non un problema di endianness, come si poteva vedere qui:

$ perl -e "print unpack('H8', pack ('f', unpack('f', pack('H8', '000088ff'))));"; 
0000c8ff 
+1

Ho scritto un bug report su rt.perl. org: https://rt.perl.org/Ticket/Display.html?id=120405 –