da decimale a IEEE-754 single precision

[LoScienziato]

Salve mi potreste spiegare come convertire il numero 2^-135 in decimale secondo lo standard IEEE-754 a singola precisione?

Secondo la "scaletta" io dovrei:

1) convertire in binario il numero
2) normalizzarlo
3) codificare il segno
4) calcolare l'esponente polarizzato

Penso di avere problemi nel punto 1) come lo converto 2^-135 in binario?

Grazie

[LoScienziato]

Grazie per le risposte, anche secondo me non era rappresentabile ma mi è stato consigliato di provare a fare 2^-126 * 2^-9 possibile?

verrebbe fuori "0 00000000 0000000010000000000"

dove l'1 è messo in 9° posizione della mantissa

[xyz]

Quel numero è non rappresentabile nello standard IEEE 754 a 32-bit come ti è stato detto.

Se non credi alla matematica puoi sempre provare a generare tu il numero giocando con i bit della mantissa e esponente:

https://evanw.github.io/float-toy

[LoScienziato]

Non è che non ci credo, anche a me non sembrava rappresentabile, eppure era presente in un esame universitario.
Probabile che abbia sbagliato il docente

[DavideDaSerra]

Vero, l'esponente può essere o un (signed) short o un unsigned short (intero a 8 bit), lo stesso numero, ma con esponente positivo, avresti quindi potuto quindi rappresentarlo.

[MassimoB]

l'esponente può essere o un (signed) short o un unsigned short (intero a 8 bit),

No

[EcoTan]

Leggo dall'help del mio basic:
Singles are stored as signed 32 bit binary numbers. Ranging in value from 1.5 x 10^–45 to 3.4 x 10^38
Dalla calcolatrice del Windows ottengo che:
2^-135=2,29e-41 cioè 2^-135 = 2,29 x 10^-41
quindi ci dovremmo stare dentro.

Allora si fa:
#include "math.h"
float prova;
prova = pow(2,-135);

[xyz]

Non ha senso di parlare di signed e unsigned dell'esponente, lo standard IEEE 754 prevede solo il signed e anche con esponente positivo il numero non è rapresentabile.

Se usate il GCC come compilatore definisce 2 variabili "__FLT_MAX__" e "__FLT_MIN__" che contengono il valore minimo e massimo del tipo "float", con il seguente comando è possibile vedere i limiti:

Codice: Seleziona tutto

echo | gcc -E -dM - | grep "__FLT_M\(IN\|AX\)__"

#define __FLT_MIN__ 1.17549435082228750796873653722224568e-38F
#define __FLT_MAX__ 3.40282346638528859811704183484516925e+38F


Se avete inlcude "float.h" sono definite 2 variabili "FLT_MAX" e "FLT_MIN" allo stesso modo.

La funzione "pow" della libreria matematica C è definita in double non in float (man pow):

Codice: Seleziona tutto

double pow(double x, double y);

Molto probabilmente la calcolatrice di MS-Windows calcola almeno in double e non in float.

[EcoTan]

Leggo dall'help del mio basic:
Singles are stored as signed 32 bit binary numbers. Ranging in value from 1.5 x 10^–45 to 3.4 x 10^38
Dalla calcolatrice del Windows ottengo che:
2^-135=2,29e-41 cioè 2^-135 = 2,29 x 10^-41
quindi ci dovremmo stare dentro.

A bella posta ho citato la fonte delle mie informazioni perché so che la materia è "scivolosa".
Forse non mi sorprende che il Basic (parlo di Bascom per AVR) attribuisca, al formato floating a 32 bit, dei limiti massimo e minimo un po' diversi rispetto al C.

[xyz]

Sono andato a leggermi la revisione dello standard IEEE 754 chiamato IEEE 754-2008, prevede l'uso dei numeri non normalizzati:

https://en.wikipedia.org/wiki/Denormal_number

in pratica invece di avere la mantissa (normalizzata) con 1 al primo posto del tipo 1.xxxxxx si può avere la mantissa (non normalizzata) con degli zeri iniziali. Nella revisione IEEE 754-2008 per indicare un numero non normalizzato l'esponente con bias deve essere zero.

Quindi usando la revisione dello standard il numero può essere rappresentato in questo modo in binario e esadecimale:

Codice: Seleziona tutto

0b00000000000000000100000000000000
0x00004000

il quale rappresenta il numero aprossimato uguale a come indicato nel post [4]

Quindi il numero incriminato non può essere rappresentato nello standard IEEE 754 ma nella sua revisione IEEE 754-2008. Aggiungo che l'uso dei numeri float con mantissa non normalizzata provoca una perdita di precisione, l'intervallo tra i numeri consecutivi è logaritmico e si ha un rallentamento nei calcoli, FPU non è in gradi di eseguire i calcoli rapidamente rispetto all'uso di una mantissa normalizzata.