Problema Incremento Numero Real

[rinon81]

Buon giorno a tutti,

Questa mattina mi sono accorto che il contachilometri della macchina sulla quale lavoro si era bloccato.Analizzando il SW mi sono accorto che

il semplice calcolo che utilizzo per incrementare il mio contachilometri arrivati a questo valore 1.677722e+007 non viene piu' incrementato!!

Sapete spiegarmi il perche'?

il mio incremento nel SW e' fatto cosi:

L DB1.DBD 0

L 1.000000e+000

+R

T DB1.DBD 0

Grazie

Saluti

Rino

[batta]

Perché il formato REAL a 32 bit utilizza 24 bit per la mantissa, 8 bit per l'esponente e 1 bit per il segno.

Il massimo valore intero che rieschi quindi a rappresentare senza perdere precisione, è 2^24 = 16777216.

Se a quel valore sommi una unità, non ottieni nessun risultato perché viene persa con le approssimazioni.

Contatori di questo tipo è meglio farli con una variabile di tipo DINT.

Con una DINT arrivi fino a 2147483647 (4294967295 senza segno).

[Giuseppe Signorella]

Perché il formato REAL a 32 bit utilizza 24 bit per la mantissa, 8 bit per l'esponente e 1 bit per il segno.

Che io sappia sono 23 bit per la mantissa, 8per l'esponente ed 1 per il segno Totale 32 bit

Il bit di segno è il più significativo

Modificato: 21 gennaio 2013 da Giuseppe Signorella

[batta]

Sì, sono 23 bit.

Anche perché 24 + 8 + 1 = 33

[spatula]

La discussione ha già chiarito l'essenziale, ma penso sia utile aggiungere che non tutti i processori seguono lo standard (IEEE 754) nel trattamento dei floating point. Non ho idea di cosa parliamo in questo caso, ma mi è capitato di vedere processori con bit di segno distinti per mantissa ed esponente, che oltretutto potevano essere interpretati sia come signed che come unsigned, insomma sia 24+8 che 23+1+7+1.

Se la mantissa viene interpretata come unsigned vale il limite di 2^24 indicato per primo da batta, che corrisponde a quanto osservato. Osservo anche che fino a 2^24-1 il numero può essere rappresentato internamente in due modi: come un intero 16777215e0, o come 1,6777215e+007. La mia ipotesi è che il processore inizi trattando il numero come un intero (esponente 0) senza segno, fino a che l'ulteriore incremento fa passare alla rappresentazione con la virgola ed esponente +007. A questo punto il fatto che perda di precisione (in 1.677722e+007 ci sono 6 decimali anziché 7) mi fa pensare che la mantissa sia ora rappresentata su 23 bit, interpretando il bit più significativo della mantissa come bit di segno.

Il risultato è quello di cui si è già detto ma la matematica mi convince di più.