Double vs FLOAT - erreur MathFloor peu claire - page 6
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Oui.
Merci.
Alors pourquoi cela fonctionne-t-il sans normalisation et sans MathFloor ?
Si l'entrée est de 0,95 ?
{
double ask2 = 1.55557, ask3 = 1.55558, bid = 1.55555;
Print("(ask2 + bid)/2 = ", (ask2 + bid)/2);
Print("(ask3 + bid)/2 = ", (ask3 + bid)/2);
int avPrice_2 = (int)NormalizeDouble((ask2/_Point + bid/_Point)/2, 0);
int avPrice_3 = (int)NormalizeDouble((ask3/_Point + bid/_Point)/2, 0);
Print("avPrice_2 = ", avPrice_2);
Print("avPrice_3 = ", avPrice_3);
}/*******************************************************************/
2017.02.27 00:03:54.456 00 (EURUSD.m,H1) (ask3 + bid)/2 = 1.555565
2017.02.27 00:03:54.456 00 (EURUSD.m,H1) avPrice_2 = 155556
2017.02.27 00:03:54.456 00 (EURUSD.m,H1) avPrice_3 = 155557
" Prenez l'offre et la demande. et calculez le prix moyen. Si l'écart est impair (3,5,7,9, etc.), il faut alors assimiler le prix moyen plus proche de l'offre."
La tâche n'est pas fixée :
- Que signifie un écart bizarre. 1,3,...,9 fois le point ou 1,3,...,17,57 fois le point ? Les arrondis fonctionnent dans les segments d'unités...
- que signifie "plus près du Bid" ? En particulier si l'écart est de 43 fois Point, par exemple. On parle d'assimiler le Bid à quoi ?
Il faut d'abord clarifier le problème, ce n'est qu'ensuite qu'une décision sans ambiguïté peut être prise.
En même temps, puisque nous parlons de nombres pairs/impairs, il serait logique de passer aux nombres entiers, où ce concept a du sens.
double Ask,Bid,Middle; // Уже известные курсы Ask и Bid, вычисляемый средний курс
int Mash,Spr; // Множитель перехода к целым числам. Для 4-разрядного EURUSD 10000. И целочисленный спред
Mash=MathRound(1.0/_Point);
Spr=MathRound((Ask-Bid)*Mash); // Целочисленный спред
// Придаем конкретность среднему курсу. Предполагаем, что "ближе к Бид" значит "ближайший меньший среднего арифметического Ask и Bid, кратный Point"
Spr=Spr >> 1; // Целочисленный спред, деленный на 2 с отбрасыванием остатка
Middle=Bid+Spr*_Point;
// Если предположение неверно, канва последующих разборов такая
if ((Spr & 1) != 0)) { // Спред нечетный
}
else { // Спред четный
}
" Prenez l'offre et la demande. et calculez le prix moyen. Si l'écart est impair (3,5,7,9, etc.), il faut alors assimiler le prix moyen plus proche de l'offre."
La tâche n'est pas fixée :
En fait, la tâche semble simple ? et elle peut être réalisée par un écolier ? :-) C'est ce que je pensais aussi.
Mais dans la tarification du serveur, la normalisation des données et le reste - il y a des coins sombres que vous ne soupçonnez même pas.
Je programme en mql depuis 9 ans - et je n'ai jamais eu de problème de normalisation parce que je l'ai bien fait. et la précision à 1 millipoint a toujours fonctionné correctement.
Mais il y a des tâches qui nécessitent une grande précision.
Et il y a des conditions.
A savoir :
Nous devons donc normaliser le prix de manière à ce que, s'il y a un résidu (et il y en aura un même avec un écart égal ! :-)), nous fassions la moyenne du prix le plus proche du point bas, c'est-à-dire de l'offre.
Par exemple :
Et tout semble être simple ? Tout devrait fonctionner et je suis moi-même un idiot ? et je suis resté assis pendant 2 jours en espérant ne pas être un idiot. Comprendre les queues et les dabbles et les tribbles et les bibbles..................
Mais ! avec la même formule, avec des écarts pairs et des écarts impairs - dans certaines situations - la formule ne fonctionnait pas . (voir ci-dessus) .
Notamment, il peut fonctionner sur les devises et ne pas fonctionner sur le pétrole.
Il se peut qu' il fonctionne sur le JPY et ne fonctionne pas sur le USD à un moment donné.
Peut-être regarde-t-elle l'influence de la lune ? Le temps en Afrique .................
Mais, quand vous êtes sûr que la formule fonctionne, vous ne remarquez pas ce 1 millipoint. et vous travaillez sur..... et puis "Bang, bang, bang, bang" et ce millipoint, décide de s'enfuir, ou d'appeler le deuxième millipoint, qui se met en travers.
IMHO.
Vous pouvez me considérer comme un idiot, un sous-programmeur, un écolier..... et ainsi de suite.
Mais le fait demeure.
Une erreur se produit avec différentes combinaisons de valeurs doubles. En même temps, tout est clair avec le flotteur.
Je ne l'ai pas encore compris. L'aide est très bonne et je demande toujours de l'aide, c'est normal. Et je demanderai peut-être de l'aide à la communauté dans 10 ans. C'est normal. Et je réponds à un appel à l'aide si je connais les pièges - c'est normal.
Bien sûr, après de tels tests, je ferai une "enquête supplémentaire" pour comprendre par moi-même pourquoi c'est le cas.
Merci à tous pour votre réactivité et votre aide.
En fait, la tâche semble être simple... Et elle peut être réalisée par un écolier ? :-) C'est ce que je pensais aussi.
Mais il y a des coins tellement sombres dans les prix obtenus du serveur, dans la normalisation des données et le reste - que vous n'y pensez même pas.
Je programme en mql depuis 9 ans - et je n'ai jamais eu de problème de normalisation parce que je l'ai bien fait. et la précision à 1 millipoint a toujours fonctionné correctement.
Mais ! avec la même formule, avec des écarts pairs et des écarts impairs - dans certaines situations - la formule ne fonctionnait pas . (voir ci-dessus) .
Avec des combinaisons différentes - avec des valeurs doubles, une erreur se produit. En même temps, avec le flotteur, tout est clair.
Qu'est-ce que la version de Metakvotes de la normalisation des données a à voir avec cela de toute façon ? Ce terme a des significations différentes pour les programmeurs et n'est pas du tout un arrondi. Lisez la norme IEEE 754, par exemple, ici: http://www.softelectro.ru/ieee754.html. Les nombres réels non normalisés vont jusqu'à 1,17549421*10^(-38) en cas de longueur de 4 octets et jusqu'à 4....*10^(-324) en cas de longueur de 8 octets, nous les rencontrons très rarement et certainement pas dans les calculs de cours. Si vous devez appeler OrderSend, arrondissez-le en fonction des exigences de cette fonction. Il n'est pas nécessaire d'utiliser les arrondis tant que la tâche ne l'exige pas.
Les erreurs ne se produisent pas dans le format double ou flottant, mais dans les opérations utilisées. Le fait que la formule n'ait pas résolu la tâche vous indique qu'elle n'est pas appropriée pour cette tâche. Pas plus que ça. Dites-moi quelles erreurs se produisent dans un calcul normal sans normalisation (c'est le morceau de mon post ci-dessus) :
Spr=MathRound((Ask-Bid)/_Point) ; Spr=Spr >> 1; Middle=Bid+Spr*_Point ;
En fait, la tâche semble simple... Et elle peut être réalisée par un écolier ? :-) C'est ce que je pensais aussi.
Mais il y a des coins tellement sombres dans les prix obtenus du serveur, dans la normalisation des données et le reste - que vous n'y pensez même pas.
Je programme en mql depuis 9 ans - et je n'ai jamais eu de problème de normalisation parce que je l'ai bien fait. et la précision à 1 millipoint a toujours fonctionné correctement.
Mais il y a des tâches qui nécessitent une grande précision.
Et il y a des conditions.
A savoir :
Nous devons donc normaliser le prix de manière à ce que, s'il y a un résidu (et il y en aura un même avec un écart égal ! :-)), nous fassions la moyenne du prix le plus proche du point bas, c'est-à-dire de l'offre.
Par exemple :
Et tout semble être simple ? Tout devrait fonctionner et je suis moi-même un idiot ? et je suis resté assis pendant 2 jours en espérant que je ne suis pas un idiot. Comprendre les queues et les dabbles et les tribbles et les bibbles..................
Mais ! avec la même formule, avec des écarts pairs et des écarts impairs - dans certaines situations - la formule ne fonctionnait pas . (voir ci-dessus) .
Notamment, il peut fonctionner sur les devises et ne pas fonctionner sur le pétrole.
Il se peut qu' il fonctionne sur le JPY et ne fonctionne pas sur le USD à un moment donné.
Peut-être regarde-t-elle l'influence de la lune ? Le temps en Afrique .................
Mais, quand vous êtes sûr que la formule fonctionne, vous ne remarquez pas ce 1 millipoint. et vous travaillez sur..... et puis "Bang, bang, bang, bang" et ce millipoint, décide de s'enfuir, ou d'appeler le deuxième millipoint, qui se met en travers.
IMHO.
Vous pouvez me considérer comme un idiot, un sous-programmeur, un écolier..... et ainsi de suite.
Mais le fait demeure.
Une erreur se produit avec différentes combinaisons de valeurs doubles. En même temps, tout est clair avec le flotteur.
Je ne l'ai pas encore compris. L'aide est très bonne et je la demande toujours, c'est normal. Et je demanderai peut-être l'aide de la communauté dans 10 ans. C'est normal. Et je réponds à un appel à l'aide si je connais les pièges - c'est normal.
Bien sûr, après de tels tests, je ferai une "enquête supplémentaire" pour comprendre par moi-même pourquoi c'est le cas.
Merci à tous pour votre réactivité et votre aide.