Paradosso NormalizeDouble - pagina 2

 
transcendreamer:
La rottura del modello è che anche dopo la normalizzazione ci sono ancora code!
Non ci sono code dopo la normalizzazione... Non ingannare la gente.
 
VOLDEMAR:
Nessuna coda dopo la normalizzazione... Non ingannare la gente.

Non entro in .... ma ho

la situazione è questa: normalizzo un numero doppio, lo scrivo in una variabile globale del terminale, poi lo leggo, lo normalizzo di nuovo e ottengo code!

infine - non ho il potere di prendere queste code - le ho appena tagliate forzatamente usando DoubleToStr(current,2)

 
transcendreamer:

Non entro in .... ma ho

la situazione è questa: normalizzo un numero doppio, lo scrivo in una variabile globale del terminale, poi lo leggo, lo normalizzo di nuovo e ottengo code!

di conseguenza - nessuna energia per prendere queste code - le ho appena prese e tagliate con la forza usando DoubleToStr(current,2)

Se si normalizza la variabile double, per esempio, a 5 caratteri, allora la variabile memorizzerà 5 caratteri, nel caso di raprinters e altro, si converte la variabile in un tipo di dati diverso, il che può causare code.

Ma non c'è coda nel doppio dopo la normalizzazione...

Per non ottenere un crash, è necessario fare la normalizzazione nei punti dell'applicazione, nel corso dei calcoli...

 
VOLDEMAR:

Se si normalizza una variabile doppia a 5 cifre per esempio, la variabile memorizzerà 5 cifre, in caso di ristampa e altre cose si converte la variabile in un altro tipo di dati e una coda può apparire come conseguenza.

ma non c'è coda nel doppio dopo la normalizzazione...

Per non ottenere un crash, la normalizzazione dovrebbe essere fatta nei punti dell'applicazione, non si può fare nel corso dei calcoli...

Cioè, se faccio, per esempio, una trasformazione
(string)current

allora può dare delle code proprio durante questa conversione?

non sapeva

Grazie!

 
transcendreamer:
Cioè, se faccio, per esempio, una trasformazione
(string)current

allora potrebbe dare delle code proprio in questo processo di conversione?

non lo sapeva.

Grazie!

Sì, DoubleToString(, 5) è corretto
 
stringo:

NormalizeDouble funziona esattamente così (e ha sempre funzionato così dal primo MQL)

Il numero viene moltiplicato per 10 alla potenza delle cifre, convertito in forma intera (scartando la parte frazionaria), e poi diviso per 10 alla potenza delle cifre

Qual è il problema qui? C'è un'interruzione del modello?

La parte frazionaria viene buttata via? L'arrotondamento è fatto da.

NormalizeDouble(1.25,1) = 1.3

 
Integer:

La parte frazionaria viene scartata? Viene eseguito l'arrotondamento.

NormalizeDouble(1.25,1) = 1.3

Sì, ho dimenticato di menzionare l'arrotondamento. L'arrotondamento viene applicato quando si ottiene un numero intero.
 
transcendreamer:
Quindi se faccio, per esempio, una conversione
(string)current

allora potrebbe dare delle code proprio in questo processo di conversione?

non lo sapeva.

grazie!

Non proprio. Sistema binario != sistema decimale. I decimali binari sono 0,5 / 0,25 / 0,125 / 0,0625 / 0,03125, ecc. Non è possibile sommare tutte le cifre decimali di questi mattoni. Per esempio è impossibile mettere insieme un numero decimale 0,3 esattamente (si può solo mettere insieme un valore approssimativo), nel sistema binario sarà o un po' meno o un po' più. Ecco come appare questa coda.

Solo i numeri divisibili senza resto per 1/2^ qualsiasi potenza sono rappresentati accuratamente.

In altre parole, distorciamo i numeri quando cerchiamo di rappresentare i numeri decimali in forma binaria.

 
Una tale analogia:
Siamo abituati al fatto che per non scrivere esattamente il risultato di un'operazione 1/3 dovrà arrotondare. Ma nel sistema ternario c'è una rappresentazione esatta dell'operazione == 0,1. Se il nostro sistema nativo fosse ternario e il pc lavorasse con il decimale, saremmo sorpresi dalla spazzatura in bit quando si riconverte in ternario il numero 0,1troico.
 
pavlick_:
Una tale analogia:
Siamo abituati a non scrivere esattamente il risultato di un'operazione di 1/3 che dobbiamo arrotondare. Ma nel sistema ternario c'è una rappresentazione esatta dell'operazione == 0,1. Se il nostro sistema nativo fosse ternario e il pc lavorasse con il decimale, saremmo sorpresi dalla spazzatura in bit quando si riconverte in ternario il numero 0,1troico.

Questo è vero.

Ma per qualche ragione, anche una calcolatrice da un centesimo può leggere un numero dalla memoria e restituire esattamente ciò che vi era scritto.

Si scrive una frazione 1,23 e si ottiene esattamente 1,23 senza alcuna coda.

Ed ecco il trucco.

in teoria, l'utente dovrebbe essere libero da una routine come presentare il numero in formato binario

<modalità bore off>.

Motivazione: