La libreria standard ha una funzione di normalizzazione dei prezzi che tiene conto della granularità
Sono consapevole di questa implementazione estremamente lenta. Si trattava di mettere a punto NormalizeDouble (e Help) per le realtà attuali. Ognuno può scrivere le proprie granularità.
transcendreamer: Stavo cominciando a pensare che NormalizeDouble(new_lot-sum_lots,Lots_Digits); non produce esattamente 0 e memorizza qualche coda
Se le variabili new_lot e sum_lots sono uguali, allora la differenza è esattamente 0. Ma non si sa come li calcoli, possono effettivamente essere disuguali quando vengono calcolati, da cui la differenza non zero. Fate la stessa cosa in questo modo:
Se le variabili new_lot e sum_lots sono uguali, allora la differenza è esattamente 0. Ma non si sa come li calcoli, possono effettivamente essere disuguali quando vengono calcolati, da cui la differenza non zero. Fate la stessa cosa in questo modo:
OrderLots dovrebbe probabilmente restituire dubs normalizzati,
ma in qualche modo a volte in rare occasioni ottengo numeri come 2.775557561562891e-17
Quindi è quasi zero ma non zero.......
prima domanda - è normale?
...
L'ho letto di nuovo attentamente. Non è normale. Se funzione NormalizeDouble:
Si seleziona la parte intera - I
La parte frazionaria è selezionata - F
F = F * 10^digit
F = F (+ o - a seconda del segno) 0,5
F = (parte intera di F) / 10^digit
risultato = I + F
allora anche il risultato diNormalizeDouble(new_lot - sum_lots, Lots_Digits) dovrebbe essere strettamente zero se new_lot e sum_lots sono uguali entro il numero di cifre specificato. In rari casi ci può essere una differenza di 1 nell'ultima cifra (la ragione è nei punti 4 e 5), ma il risultato 2.775557561562891e-17 è strano, non dovrebbe essere.
Ho scritto un piccolo codice tutorial (ero interessato a curiosare io stesso) che scopre le interiora di un numero fluttuante. Se qualcuno è interessato, è possibile eseguirlo (codice C++, si può usare qualche compilatore online. Qui https://goo.gl/tP691X, per esempio)
Ho scritto un piccolo codice tutorial (ero interessato a curiosare io stesso) che scopre le interiora di un numero fluttuante. Se qualcuno è interessato, è possibile eseguirlo (codice C++, si può usare qualche compilatore online. Qui https://www.tutorialspoint.com/compile_cpp11_online.php, per esempio)
Potete anche eseguirlo in MQL5 - sostituite c[Pos] con _R(f)[(char)Pos] (o _R(f).Bytes[Pos]) collegando questa libreria.
2016.09.2723:56:01.178 Test (Si-12.16,H1) 02016.09.2723:56:01.178 Test (Si-12.16,H1) sign
2016.09.2723:56:01.178 Test (Si-12.16,H1) 128= 02016.09.2723:56:01.178 Test (Si-12.16,H1) 64= 12016.09.2723:56:01.178 Test (Si-12.16,H1) 32= 12016.09.2723:56:01.178 Test (Si-12.16,H1) 16= 12016.09.2723:56:01.178 Test (Si-12.16,H1) 8= 12016.09.2723:56:01.178 Test (Si-12.16,H1) 4= 12016.09.2723:56:01.178 Test (Si-12.16,H1) 2= 12016.09.2723:56:01.178 Test (Si-12.16,H1) 1= 02016.09.2723:56:01.178 Test (Si-12.16,H1) exponenta E - 127:
2016.09.2723:56:01.178 Test (Si-12.16,H1) implicit_1 03203203203203203203203203203203203203203203203203203203203203203212016.09.2723:56:01.178 Test (Si-12.16,H1) mantissa:
2016.09.2723:56:01.178 Test (Si-12.16,H1) ----------
2016.09.2723:56:01.178 Test (Si-12.16,H1) value = 0.5000000596046448
32 è il codice ascii del problema. Sembra che la libreria con l'errore non abbia una versione char. Penso che dobbiamo eliminare i problemi tra i valori di mantissa. O forse invece di ' ' scrivere " "?
32 è il codice ascii del problema. Sembra una biblioteca con un bug. Penso che dobbiamo eliminare i problemi tra i valori di mantissa. O forse invece di ' ' scrivere " "?
Il fmtprntl.mqh non è mio, quindi non posso dirlo con certezza.
Non voglio disturbare, quindi per i vostri valori di byte stampati f
2016.09.2800:34:09.813 Test (Si-12.16,H1) c[0] = 12016.09.2800:34:09.813 Test (Si-12.16,H1) c[1] = 02016.09.2800:34:09.813 Test (Si-12.16,H1) c[2] = 02016.09.2800:34:09.813 Test (Si-12.16,H1) c[3] = 63
Consenti l'uso dei cookie per accedere al sito MQL5.com.
Abilita le impostazioni necessarie nel browser, altrimenti non sarà possibile accedere.
Hai effettuato l'accesso. L'autenticazione a due fattori è stata disattivata. Configurala di nuovo e scansiona un nuovo codice QR, oppure continua con l'autenticazione a due fattori disattivata.
Obsolete
La libreria standard ha una funzione di normalizzazione dei prezzi che tiene conto della granularità
La libreria standard ha una funzione di normalizzazione dei prezzi che tiene conto della granularità
Stavo cominciando a pensare che NormalizeDouble(new_lot-sum_lots,Lots_Digits); non produce esattamente 0 e memorizza qualche coda
Se le variabili new_lot e sum_lots sono uguali, allora la differenza è esattamente 0. Ma non si sa come li calcoli, possono effettivamente essere disuguali quando vengono calcolati, da cui la differenza non zero. Fate la stessa cosa in questo modo:
NormalizeDouble(new_lot, Lots_Digits) - NormalizeDouble(sum_lots, Lots_Digits).
Se le variabili sono uguali entro il numero specificato di cifre, allora la differenza sarà strettamente 0.
Se le variabili new_lot e sum_lots sono uguali, allora la differenza è esattamente 0. Ma non si sa come li calcoli, possono effettivamente essere disuguali quando vengono calcolati, da cui la differenza non zero. Fate la stessa cosa in questo modo:
NormalizeDouble(new_lot, Lots_Digits) - NormalizeDouble(sum_lots, Lots_Digits).
Se le variabili sono uguali entro il numero di cifre specificato, la differenza sarà strettamente 0.
Ancora sull'arrotondamento......
Per favore consigliatemi sulla situazione (per favore non tirate pomodori, sono un umanitario),
esiste una tale variabile:
double delta=NormalizeDouble(new_lot-sum_lots,Lots_Digits);
if(delta>0) delta-=OrderLots();
if(delta<0) delta+=OrderLots();
Il delta è originariamente normalizzato,
OrderLots dovrebbe probabilmente restituire dubs normalizzati,
ma in qualche modo a volte in rare occasioni ottengo numeri come 2.775557561562891e-17
Quindi è quasi zero ma non zero.......
prima domanda - è normale?
...
L'ho letto di nuovo attentamente. Non è normale. Se funzione NormalizeDouble:
- Si seleziona la parte intera - I
- La parte frazionaria è selezionata - F
- F = F * 10^digit
- F = F (+ o - a seconda del segno) 0,5
- F = (parte intera di F) / 10^digit
- risultato = I + F
allora anche il risultato diNormalizeDouble(new_lot - sum_lots, Lots_Digits) dovrebbe essere strettamente zero se new_lot e sum_lots sono uguali entro il numero di cifre specificato. In rari casi ci può essere una differenza di 1 nell'ultima cifra (la ragione è nei punti 4 e 5), ma il risultato 2.775557561562891e-17 è strano, non dovrebbe essere.Ho scritto un piccolo codice tutorial (ero interessato a curiosare io stesso) che scopre le interiora di un numero fluttuante. Se qualcuno è interessato, è possibile eseguirlo (codice C++, si può usare qualche compilatore online. Qui https://goo.gl/tP691X, per esempio)
L'uscita a f == 0,5 + 1/(2^24). 1/(2^24) è la cifra meno significativa della mantissa ad un dato grado:
Grado = 126 - 127 = -1
mantissa = 1.000000000000000000000000001
Spostare la mantissa al grado -1 = 0,1000000000000000000001 = 1^(-1) + 1^(-24) = 1/(2^1) + 1/(2^24) = 0,5 + 0,00000005960464478 = 0,50000005960464478
Come teoria https://habrahabr.ru/post/112953/.
SZZ: questo compilatore online è più bello di http://rextester.com/l/cpp_online_compiler_gcc
Ho scritto un piccolo codice tutorial (ero interessato a curiosare io stesso) che scopre le interiora di un numero fluttuante. Se qualcuno è interessato, è possibile eseguirlo (codice C++, si può usare qualche compilatore online. Qui https://www.tutorialspoint.com/compile_cpp11_online.php, per esempio)
Potete anche eseguirlo in MQL5 - sostituite c[Pos] con _R(f)[(char)Pos] (o _R(f).Bytes[Pos]) collegando questa libreria.
SZ
Risultato
Cosa è successo alla mantissa?
32 è il codice ascii del problema. Sembra che la libreria con l'errore non abbia una versione char. Penso che dobbiamo eliminare i problemi tra i valori di mantissa. O forse invece di ' ' scrivere " "?
Cosa è successo alla mantissa?
32 è il codice ascii del problema. Sembra una biblioteca con un bug. Penso che dobbiamo eliminare i problemi tra i valori di mantissa. O forse invece di ' ' scrivere " "?
Il fmtprntl.mqh non è mio, quindi non posso dirlo con certezza.
Non voglio disturbare, quindi per i vostri valori di byte stampati f
Un effetto collaterale correlato.
Si è rivelato conveniente. Ma non era originariamente destinato ad essere usato in questo modo.
Ci sono funzioni speciali per stampare numeri reali con la precisione richiesta.
Dimmi perché hai bisogno di arrotondare i numeri reali nel processo di calcolo? Perché in questo caso, si perde la precisione del calcolo!
Stiamo parlando del corretto confronto di prezzi, fermate, lotti
Qui c'è bisogno di una certa precisione.