Erreurs, bugs, questions - page 3039

Nouveau commentaire
 
Andrei Trukhanovich:
un petit conseil - vous pouvez fermer tous les graphiques sauf celui dont vous avez besoin, alors la consommation sera à peu près la même que si votre béquille avait été implémentée.

la logique de la vieille école

Je l'aisur VPS, mais je suis désolé. Je ne veux pas être limité par quoi que ce soit.
 
Igor Makanu:

Si nous parlons maintenant de consommation de mémoire, je me souviens qu'il y a quelques mois@fxsaber avait le même problème, mais lors du chargement des ticks - après avoir libéré les tableaux avec les ticks, le terminal ne libère pas la mémoire, mais stocke (pendant 10 secondes ?) ces ticks comme un cache.

Il est très probable que votre demande aura le même problème - la consommation de mémoire ne diminuera pas mais au contraire augmentera ( à la pelle ).

Je ne comprends pas pourquoi.
Je sais comment utiliser la fonction ArrayFree.
En particulier, je n'utiliserai la fonction que je demande qu'une seule fois. Mais en même temps, je n'ai pas besoin d'allumer Illimité.
L'histoire complète d'un outil tient dans les 80 à 100 Mo (à la fois en RAM et sur le disque). Maintenant, il y a environ 500 Mo sur le disque.
J'allume le terminal et je charge le tableau de structures du fichier dans la mémoire et je travaille en paix. Pas de pics du tout.
J'utiliserais une structure de données normale. L'enfer d'avoir beaucoup d'espace. Mais j'ai besoin de temps pour le High et le Low.
J'utilise déjà les ticks dans toute la mesure du possible pour façonner ma structure de données, mais ils n'ont pas toute la profondeur de l'historique et ont tendance à ne pas correspondre aux barres de minutes. J'ai des ticks et pas de barres, ou j'ai des barres et pas de ticks.

 
Nikolai Semko:

Bien, vous vous tirez une balle dans le pied - il y a déjà d'innombrables options.
Juste en mettant max_bars =Unlimited, la consommation de mémoire augmente dramatiquement.
Voici un exemple du terminal avec max_bars = 5000

Maintenant changez max_bars = Unlimited et rechargez le terminal.

Avec les mêmes fenêtres ouvertes, la consommation de mémoire a augmenté de plus de Go. Dans mon cas, 11 fois plus grand ! !!!
C'est un normal ))
Vous pouvez le vérifier vous-même.
max_bars = Illimité est un luxe très difficile.
Si
ma demande était acceptée, vous ne pourriez jamais utilisermax_bars = Unlimited.
Et en plus d'économiser de la mémoire dans la RAM, cela réduirait aussi considérablement ce dossier, dont j'ai maintenant environ 31 Go. Je pense que c'est environ 5 fois plus. Et ce serait 6GB au lieu de 30GB.

Donc vous suggérez que tout le monde devrait être illimité illimité !

Si un programme a accès à tous les bars, alors tout le monde l'a.

Pourquoi les graphiques devraient-ils afficher un millier de barres si l'indicateur a accès à un million ?


Un autre problème est l'accès au format hcc et au dossier contenant les fichiers d'historique. Mais tout n'est pas simple là non plus : caches, réinitialisation économique, vérification de l'exactitude, autre chose...

 

2940

Il y avait un code indicateur : tout fonctionnait bien sur le graphique et dans le testeur.

J'ai créé une nouvelle version de l'indicateur avec les modifications apportées : il fonctionne bien dans le graphique, mais pas dans le testeur (il ne dessine rien, bien que la fenêtre de données montre des tampons et qu'ils soient vides).

J'ai passé quelques heures à le comprendre, j'ai rétabli la version précédente du code, rien n'y a fait. Seule la mise à jour dans le navigateur du terminal a aidé et le nouveau code fonctionne aussi dans le testeur, pas seulement sur le graphique.

Je pense que quelque chose est cassé dans la mise à jour automatique des compilateurs que le testeur voit, je ne vois pas d'autre raison.

 
Nikolai Semko:

J'utiliserais la structure de données habituelle. Et puis merde, il y a plein de place. Mais j'ai besoin de temps pour le High et le Low.
J'utilise déjà les ticks dans toute la mesure du possible pour façonner ma structure de données, mais ils n'ont pas toute la profondeur de l'historique et ont tendance à être désynchronisés avec les barres de minutes. J'ai des ticks et pas de barres, et ensuite j'ai des barres et pas de ticks.

S'il y avait des tiques pendant 20 ans, les utiliseriez-vous ? Je ne peux pas demander pourquoi ? )

Bon, d'accord, vous pouvez mettre en place une stratégie d'auto-adaptation super intelligente et, par intérêt, l'exécuter une fois sur un historique de tics sur 20 ans. C'est intéressant. Une fois.

Mais pas pour le travail, pas en tant qu'élément régulier.


Et si le timing est mauvais, pourquoi croyez-vous les barres ? C'est absurde.

 
Andrey Khatimlianskii:

Donc vous suggérez que tout le monde devrait devenir illimité !

Si un programme a accès à tous les bars, alors tout le monde l'a.

Pourquoi les graphiques devraient-ils afficher un millier de barres si l'indicateur a accès à un million ?


Une autre question est de permettre l'accès au format hcc et au dossier contenant les fichiers d'historique. Mais tout n'y est pas simple : caches, réinitialisation économique, vérification de l'exactitude, autre chose...

Vous n'avez pas besoin d'accéder au format hcc et au dossier contenant les fichiers d'historique. Premièrement, MQ n'acceptera jamais cela, deuxièmement, ce n'est pas nécessaire. Il suffit de récupérer le tableau M1 à partir de ces fichiers.

C'est ça le problème, je veux pouvoir ne jamais activer l'illimité. Parce qu'une telle inclusion commence à pomper des données pour tous les instruments. Mais je n'ai pas besoin de tous, juste d'un à la fois. Pourquoi voudrais-je surcharger le système en téléchargeant des centaines de Mo de données historiques supplémentaires sans aucun contrôle.

 
Andrey Khatimlianskii:

Y aurait-il eu des tics dans 20 ans, les auriez-vous utilisés ? Ne puis-je pas me demander - pourquoi ? )

Bon, d'accord, vous pourriez mettre en place une stratégie d'auto-adaptation super intelligente et, par intérêt, l'exécuter une fois sur un historique de 20 ans. C'est intéressant. Une fois.

Mais pas pour le travail, pas en tant qu'élément régulier.


Et si le timing est mauvais, pourquoi croyez-vous les barres ? Ce n'est pas du tout le cas.

Il ne s'agit pas d'une stratégie, mais de la visualisation correcte d'un cadre temporel dynamique, qui est beaucoup plus intuitif et pratique que le système de cadre temporel archaïque existant.
Également pour la possibilité d'effectuer des tests internes "à la volée".
Bien que cela puisse également affecter la précision des stratégies dans un sens positif.

Eh bien, voici au moins un petit exemple :
Comment construire un ZigZag régulier, lorsque vous ne savez pas quel événement s'est produit en premier, Haut ou Bas ?




ou



si vous essayez de le comprendre pour des barres quotidiennes, il n'y a aucune garantie qu'avec max_bars = 50 000, vous puissiez charger des échelles temporelles inférieures pour une heure de barre donnée, ainsi que des ticks.

 
Erreur pendant l'exécution : 
void OnStart()
{
    uchar  array[];
    const string text = "All Files\0*.*\0\0";
    const int start = 0, count = StringLen( text );
    Print( StringToCharArray( text, array, start, count ), ":", count );
}

Résultat : 10:15

Attendu 15:15

Je voulais utiliser le résultat dans la fonction WinAPI GetSaveFileNameA, mais je ne peux pas le faire à cause d'un bogue.


 
A100:

C'est le cas depuis longtemps. Les chaînes mql n'aiment vraiment pas les caractères nuls à l'intérieur d'une chaîne et dans les littéraux, dans les fonctions aussi.

La seule façon normale est de traduire trois chaînes de caractères avec un null à la fin en un tableau.

Autrement dit, le comportement actuel a été adopté intentionnellement il y a quelques années. Je ne sais pas pourquoi.
 
Andrei Trukhanovich:

C'est le cas depuis longtemps. Les chaînes mql n'aiment vraiment pas les caractères nuls à l'intérieur d'une chaîne et dans les littéraux, dans les fonctions aussi.

La seule façon normale est de traduire trois chaînes de caractères avec un null à la fin en un tableau.

C'est-à-dire que ce comportement tel qu'il est maintenant a été fait intentionnellement il y a quelques années. Je ne connais pas les raisons.

Et quelle fonction, à part StringToCharArray, ne fonctionne pas correctement avec les nuls internes ?

Par exemple StringToShortArray - fonctionne sans erreur.

StringCompare fonctionnait de manière incorrecte, mais cela a été corrigé il y a longtemps.

Quant à StringLen, il ne fonctionne pas correctement.

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie

Bugs, bugs, questions

A100, 2019.05.15 13:45

Juste des erreurs partiellement corrigées .... pourquoi pas ? Dans ma mémoire, StringLen a toujours fonctionné correctement (au moins en x32).

1...303230333034303530363037303830393040304130423043304430453046...3184
Nouveau commentaire
Raison: