Mon approche. Le noyau est le moteur. - page 89

 
Реter Konow:

Démontrez un exemple concret.

Vous pouvez donc utiliser union pour traduire TOUS les types (y compris les chaînes) en uint .

Sinon, ce ne sont que des mots vides.

En s'appuyant sur les connaissances de quelqu'un d'autre ? Et ensuite gonfler vos joues en disant que vous avez tout fait vous-même ?

Ne pouvez-vous pas étudier et le faire vous-même ?

Tout a été mâché, donné, montré.

Ce que j'ai mis en évidence ressemble - comme l'a vraiment dit Nikolay - à un jardin d'enfants : "Je ne pense pas..., et mon père va frapper ton père, et ma mère va frapper ta mère...".

 
Реter Konow:

Alors montrez-moi votre exemple. Comment contourner la conversion d'une chaîne en uint via l'union pour la stocker dans une ressource ?

Alors, à quoi bon vous le montrer, si pour vous ce ne sont que des "mots", une "complication de l'architecture" et "la vitesse sera à peu près la même". Vous avez pris votre décision à l'avance. Vous ne voulez rien apprendre de nouveau, mais vous avez un grand aplomb.

 
Artyom Trishkin:


C'est un argument.

J'ai proposé une solution. Tout le monde l'a critiqué, mais n'a pas montré le leur. Comme, "va voir le code fxsaber, va lire l'aide...".

Aww. Les gars.)))

 
Реter Konow:

C'est un argument.

J'ai proposé une solution. Tout le monde l'a critiqué, mais n'a pas montré le leur. Comme, "va voir le code fxsaber, va lire l'aide...".

Aww. Les gars.)))

Ce n'est pas un argument. C'est une dissection de votre décision intuitive.

Je ne discute pas, vous pouvez planter un arbre dans un pot renversé, concevoir un système pour l'arroser, un système pour stocker l'eau de pluie et l'arroser dans le pot renversé, un système pour maintenir la terre dans ce pot renversé, un système d'éclairage ascendant, et prétendre... que cette solution intuitive est la plus correcte et la plus efficace, et quand les gens vous disent de regarder par la fenêtre, et ne compostiruyut cerveau - là - à l'extérieur de la fenêtre - il ya des exemples vivants de la façon dont mieux, vous, fumer une pipe sur des oreillers de satin, diffuser quelque chose de la zone de "soulever mes paupières - ne peut pas voir, me montrer, et tous ces mots vides" ... Désolé, ça a l'air drôle.

Je vais chercher du pop-corn.

 

La principale question reste sans réponse :

Comment un ensemble de données de types différents, en contournant la conversion en chaîne, peut être converti en uint via l'union, pour être stocké dans une ressource ?


Chers opposants. Vous avez critiqué ma solution en vous référant spécifiquement à l'utilisation de UNION pour traduire TOUTES les données en UINT.


AUCUN EXEMPLE N'A ÉTÉ FOURNI. JUSQU'À PRÉSENT, TOUT EST SANS FONDEMENT.


Par conséquent, une seule conclusion s'impose pour l'instant :ma solution a été décriée, conformément aux préjugés inhérents aux programmeurs.

Si la solution est démontrée, alors elle est sans doute meilleure. Je le reconnais immédiatement.

 
Реter Konow:

C'est un argument.

J'ai proposé une solution. Tout le monde l'a critiqué, mais n'a pas montré le leur. Comme, "va voir le code fxsaber, va lire l'aide...".

Aww. Les gars.)))

Peter, je vous l'ai dit à plusieurs reprises - le problème de votre approche est l'extrême étroitesse de votre public cible. Vous n'avez même pas un produit de "niche", mais juste un "créneau" - des gens qui sont assez bons en programmation, mais qui préfèrent échanger des "mains".

Regardez-vous - vous êtes surtout contesté par les codeurs, pour qui votre approche est même tout à fait compréhensible, mais très gênante. C'est pourquoi ils veulent voir de "vraies réalisations", de "vrais produits" - ils n'utiliseront pas votre approche, mais elle les intéresse en tant qu'option, et ils veulent donc évaluer "si votre approche vaut le coût", si les inconvénients de votre approche valent les bénéfices qu'elle peut potentiellement apporter.

Et vous avez besoin des autres - les vrais commerçants, qui négocient avec leurs mains. En même temps, ils sont assez bons en programmation. Ils sont capables d'écrire un conseiller expert simple, mais ont du mal à comprendre comment travailler avec des objets graphiques. Et jusqu'à présent, je ne les vois pas. C'est pourquoi vos développements ne sont pas un succès, mais ils sont constamment critiqués. Pas le bon public !

Vous avez dit quelque chose comme "nous devons les éduquer" - mais alors vous devez sûrement démontrer vos réalisations dans le trading - au moins un compte de démonstration avec une croissance constante de l'équité, qui est obtenue par ce trading très "manuel" en utilisant des objets visuels de votre bibliothèque.
 

Divers paramètres sont modifiés du côté de l'EA. Leurs valeurs doivent être transmises au moteur.

Paramètres de TOUS les types. Et de la ficelle aussi. Les valeurs à passer sont des tableaux d'entiers.

  1. Ou convertir tout en chaîne de caractères et écrire dans les descriptions d'objets.
  2. Ou convertissez-les tous en chaîne de caractères, divisez-les et passez-les par parties en utilisant OnChartEvent().
  3. Ou bien convertir tout en chaîne de caractères et convertir en char et stocker dans la ressource.
  4. Ou convertir tout en uint par une union et stocker dans la ressource.

Question :

  1. Laquelle de ces œuvres est la plus rapide ?
  2. Laquelle ne fonctionne pas du tout ?

ZS. Je soupçonne que le point 4 ne fonctionne pas du tout.

 
Georgiy Merts:

Peter, je vous l'ai dit plus d'une fois - le problème avec votre approche est l'extrême étroitesse de votre public cible. Vous n'avez même pas un produit de "niche", mais juste un produit "à créneaux" - des personnes qui sont douées pour la programmation, mais qui préfèrent faire du commerce "à la main".

Regardez vous - vous êtes surtout contesté par les codeurs, pour qui votre approche est même tout à fait compréhensible, mais très gênante. C'est pourquoi ils veulent voir de "vraies réalisations", de "vrais produits" - ils n'utiliseront pas votre approche, mais ils s'y intéressent en tant qu'option, et veulent donc évaluer "si votre approche vaut la peine", si le bénéfice qu'elle peut potentiellement apporter vaut les inconvénients.

Et vous avez besoin des autres - les vrais commerçants, qui négocient avec leurs mains. En même temps, ils sont assez bons en programmation. Qui sont capables d'écrire un conseiller expert simple, mais qui ont des difficultés à travailler avec des objets graphiques. Et jusqu'à présent, je ne les vois pas. C'est pourquoi vos développements ne sont pas un succès, mais ils sont constamment critiqués. Pas le bon public !

Il y a un public. Seulement sur d'autres sites. J'ai vu un site, ou plutôt il m'a été suggéré par un de mes clients - donc là avec un chiot delight parse le code d'un de mes experts, que j'ai écrit sur demande, et le client (pas celui qui m'a donné l'adresse pour cette discussion) l'a posté plus tard là avec une demande d'ajouter les nouveaux désirs gratuitement. Les gens ont été choqués par les approches standard. Là-bas - parmi ce public scolaire - Peter peut gratter son ego - il sera un dieu là-bas.

 
Реter Konow:

Comment contourner la conversion d'une chaîne en uint via l'union pour la stocker dans une ressource ?

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

Bibliothèques : TradeTransactions

fxsaber, 2018.12.17 23:48

Vous pouvez échanger n'importe quoi par le biais des ressources.

// Пример обмена любыми данными (включая строковые массивы).

#include <fxsaber\TradeTransactions\ResourceData.mqh> // https://www.mql5.com/ru/code/22166

#define  PRINT(A) Print(#A + " = " + (string)(A));

void OnStart()
{    
  // Произвольные данные для примера
  string Str[] = {"123", "Hello World!"};
  double Num = 5;
  MqlTick Tick = {0};
  Tick.bid = 1.23456;

  const RESOURCEDATA<uint> Resource; // Ресурс для обмена данными
  CONTAINER<uint> Container;         // Создаем контейнер - все будет храниться в массиве простого типа (в примере выбран uint)
  
  // Заполняем контейнер разными данными
  Container[0] = Str;
  Container[1] = Num;
  Container[2] = Tick;
    
  // Распечатаем типы хранимых в контейнере данных
  for (int i = 0; i < Container.GetAmount(); i++)
    PRINT(Container[i].GetType())

  Resource = Container.Data;  // Отправили данные на обмен
  
  CONTAINER<uint> Container2; // Сюда будем получать данные
  
  Resource.Get(Container2.Data); // Получили данные
      
  // Получим данные в исходном виде
  string Str2[];
  Container[0].Get(Str2);                // Получили массив
  ArrayPrint(Str2);

  PRINT(Container[1].Get<double>())      // Получили число
  PRINT(Container[2].Get<MqlTick>().bid) // Получили структуру  
}
 
Реter Konow:

Divers paramètres sont modifiés du côté de l'EA. Leurs valeurs doivent être transmises au moteur.

Paramètres de TOUS les types. Et de la ficelle aussi. Les valeurs à passer sont des tableaux d'entiers.

  1. Ou convertir tout en chaîne de caractères et écrire dans les descriptions d'objets.
  2. Ou convertissez-les tous en chaîne de caractères, divisez-les et passez-les par parties en utilisant OnChartEvent().
  3. Ou convertir tout en chaîne de caractères, puis convertir en caractères et stocker dans la ressource.
  4. Ou convertir tout en uint par une union et stocker dans la ressource.

Question :

  1. Laquelle de ces œuvres est la plus rapide ?
  2. Laquelle ne fonctionne pas du tout ?

SZY. Je soupçonne que le point 4 ne fonctionne pas du tout.

Les seules et uniques GlobalVariables et fichiers pour l'échange de données entre EAs, indicateurs et scripts sont les suivants

Les 4 points ci-dessus sont des "astuces" locales de pêche. Les 4 points ci-dessus utilisent des mécanismes qui ne sont pas destinés à échanger des données arbitraires, et encore moins des tableaux de données.

п1. 100% conduit à un verrouillage temporaire du fil d'interface (oui, les objets y vivent et leurs "descriptions" aussi) et ne fonctionne pas dans l'optimiseur. Les descriptions d'objets servent à décrire les objets de manière lisible par l'homme,

p2. n2. ne fonctionne pas dans le testeur et l'optimiseur, et sert à notifier des événements

P3. p4. les ressources (même nommées) sont destinées à un stockage à long terme, et non à un échange rapide. Je ne peux rien dire sur la convivialité dans le testeur/optimiseur :-) J'utilise des ressources en lecture seule

Cela n'a pas de sens de parler de la vitesse des solutions tordues.

ps/ d'ailleurs vous pouvez utiliser des fichiers, plus précisément des tuyaux