![MQL5 - Linguaggio delle strategie di trading integrato nel client terminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
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.