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
Je ne suis pas d'accord, il y a un problème, voici un exemple (grille 10000x10000) :
double x1=0.0011 ;
double y1=x1/10000 ;
double x2=0.0012 ;
double y2=x2/10000 ;
double c=y1-y2 ;
double d=MathPow(c,2) ;
printf(string(d)) ;
результат: 9.999999999999968e-017
Alors, que dois-je faire avec ce résultat ? Comment puis-je le comparer à d'autres résultats ? DBL_EPSILON=2.2204460492503131e-016. A part les deux derniers chiffres - tu vois ? Et ce, pour seulement deux opérations. Et j'ai d'autres de ces opérations. Et ces informations doivent être utilisées pour restaurer les données plus tard avec d'autres opérations. Plus de pertes. Je suis en train d'apprendre à programmer dans un langage de type C et une telle classe est difficile à construire pour moi (ou plutôt, je n'ai aucune idée de comment). C'est un travail sérieux. D'ailleurs, par hasard, avez-vous un tel cours ? Et les développeurs peuvent améliorer les choses pour tout le monde à la fois. Il serait possible de réaliser des grilles de 100 000x100 000. Des échantillons plus ou moins représentatifs seraient déjà disponibles, bien que cela ne suffise pas toujours. Et s'ils faisaient une classe pour la précision arbitraire, ce serait encore mieux :) C'est juste un type de données. Si elle existe, c'est qu'elle est là pour une raison, parce qu'elle répond à un besoin. Le fait est que je ne sais pas si c'est difficile ou non pour les développeurs. Si c'est difficile et coûteux - je suis d'accord avec vous - pourquoi leur refiler mon problème. Mais si ce n'est pas difficile, pourquoi ne pas le faire ? Encore une fois, un environnement de développement puissant pour des calculs commerciaux de haute précision - un avantage concurrentiel ici :). C'est pourquoi je demande ce qu'ils en pensent.
Veuillez relire la forme standard du nombre, et de nombreuses questions disparaîtront.
Dans la forme standard, 1,111e5 est plus grand que 9,999e4, la comparaison est donc tout à fait correcte.
Voici le même résultat : 9.999999999999968e-017 est lié à la représentation binaire du nombre, tous les nombres sous forme binaire ne sont pas représentés par une fraction finie, certains sont représentés par une fraction infinie, d'où l'arrondi de la mantisse au nombre le plus proche avec une fraction finie.
A propos, double d=MathPow(c,2) ; il n'est pas correct de prendre le degré, si vous travaillez avec le double, alors double d=MathPow(c,2.0) ; donc, je ne sais pas s'il y a un bug ou non, mais lorsque vous définissez un nombre en degré, vous devez également faire attention au type d'indicateur.
La fantaisie n'a rien à voir avec tout cela. Ma question portait sur la possibilité de mettre en œuvre la méthode d'analyse la plus courante. Et cela consiste à travailler avec les séries qui restent après avoir éliminé la tendance et le cycle. Il est question de cette méthode dans tous, sans exception, les manuels de statistiques financières et les livres de méthodes dans les universités. Il ne s'agit pas d'une fantaisie, mais de l'une des approches canoniques de l'analyse. Et un environnement spécialisé devrait avoir les moyens de mettre en œuvre cette approche, ne pensez-vous pas ?
Veuillez relire la forme standard du nombre, et de nombreuses questions disparaîtront.
Dans la forme standard, 1,111e5 est plus grand que 9,999e4, la comparaison est donc tout à fait correcte.
Voici le même résultat : 9.999999999999968e-017 est lié à la représentation binaire du nombre, tous les nombres sous forme binaire ne sont pas représentés par une fraction finie, certains sont représentés par une fraction infinie, d'où l'arrondi de la mantisse au nombre le plus proche avec une fraction finie.
A propos du 1.111e5 et du 9.999e4 que je vois. Mais j'ai besoin de les comparer : 9.99999999999999999999968e-017 (à propos de la perte de précision des chiffres, j'ai écrit en plus). L'aide me dit que les nombres dont la différence est inférieure à DBL_EPSILON doivent être considérés comme indiscernables. Désolé, si je ne suis pas clair - je viens juste d'apprendre :) Merci séparément pour l'information sur l'indicateur.
A propos, double d=MathPow(c,2) ; il n'est pas correct de prendre le degré, si vous travaillez avec le double alors double d=MathPow(c,2.0) ; donc, je ne sais pas si c'est un bug ou non mais quand on met un nombre en degré il faut suivre le type d'indicateur.
Chers développeurs, permettez au type void de retourner des valeurs, ou définissez une nouvelle classe qui retourne des valeurs de n'importe quel type.
Quelque chose comme ça :
Je veux avoir ce type de déclaration dans les fonctions définies par l'utilisateur :
et pour cela, je dois ajouter quelque chose à la langue. Vous avez trop sécurisé les utilisateurs, vous devez vous relâcher un peu quelque part.
Imaginez un développeur qui écrit du code, il a créé 1500 lignes et l'ensemble du code fonctionne avec un double, pour y passer un int, il devra faire une surcharge pour 1500 lignes supplémentaires. Et vous avez 14 types.
Imaginez, une personne écrit du code, fait 1500 lignes, et tout le code fonctionne avec le double, pour passer dans celui-ci vous devrez faire de la surcharge pour 1500 lignes de plus. Et vous avez 14 types.
Utilisez la POO.
Utilisez la POO.
Vous pensez que j'écris en autocode ?
aux développeurs :
afin d'alléger le sort de la fraternité des rédacteurs, il est possible d'effectuer une conversion de type tableau, afin de pouvoir au moins faire un tel appel :
Vous pensez que j'écris en autocode ?
A en juger par le fait que vous avez eu besoin d'une telle extension de la langue, je suppose que oui.
p.s. Si vous ne disposiez que du compilateur C++ au moment où vous avez résolu votre problème, entendrions-nous une suggestion de révision de la norme du langage ?
Si l'on se base sur le fait que vous aviez besoin d'une telle extension de la langue - apparemment, oui.
p.s. Si vous n'aviez que le compilateur C++ au moment de votre problème - aurions-nous entendu la suggestion de réviser la norme du langage ?
Ne confondez pas traducteur et compilateur. mql n'est pas vraiment un compilateur, c'est un traducteur décrivant des appels de fonctions C++ sûrs.
Et mql5 est en phase active de développement. Ma demande de changements est donc tout à fait adéquate.
Ne confondez pas traducteur et compilateur, mql n'est pas vraiment un compilateur, c'est un traducteur décrivant des appels de fonction C++ sûrs.
Par ailleurs, mql5 est au stade actif de son développement. Ma demande de modification est donc tout à fait adéquate.
Ok, si c'est si important, prenons Java et non C++. Egalement la traduction en bytecode :) Veuillez reconsidérer la norme linguistique ?
Une demande d'ajout d'un type universel n'est pas tout à fait adéquate. Vous devriez demander des modèles. Mais pour les types universels, la POO est suffisante.