Implémentations alternatives de fonctions/approches standard - page 13

 
Реter Konow:

Voici à quoi ressemble le début du bloc :

D'après ce que je comprends, vous avez créé votre propre langage d'interprétation.

  • vous créez l'interface elle-même sous forme de fichier texte dans cette langue
  • le corps du programme principal charge le fichier texte et le convertit en "byte-code" compréhensible, essentiellement un tableau.
  • À partir de ce tableau, les images d'interface sont générées

Comme ça ?

Une autre question idiote :

chaque fenêtre générée avec différents éléments est-elle une ressource ou plusieurs ?

Bien que, une meilleure analogie serait probablement HTML

Comme je l'ai déjà dit, votre enfant a besoin d'un constructeur graphique. Quelque chose comme celui d'Andrei Barinov.

Vos clips vidéo sont également trop longs. Vous devez les réduire de 45 minutes à 5 minutes, ou encore mieux - 3 minutes.

 
A100:

Avez-vous essayé de trouver vous-même la réponse à cette question ?

Conseil : Dans la recherche google, entrez "DBL_MANT_DIG 53 52".

Oui, merci. Je l'ai trouvé.

 
Nikolai Semko:

1. D'après ce que je comprends, vous avez créé votre propre langage d'interprétation.

  • vous créez l'interface elle-même sous forme de fichier texte dans ce langage
  • le corps du programme principal charge le fichier texte et le convertit en "byte-code" lisible par l'homme, essentiellement un tableau.
  • Ce tableau est utilisé pour générer des images d'interface.

Comme ça ?

Et une question idiote :

chaque fenêtre générée avec différents éléments est-elle une ressource ou plusieurs ?

Cependant, une meilleure analogie serait peut-être le langage HTML.

Comme je l'ai déjà dit, votre invention a besoin d'un constructeur graphique. Quelque chose comme celui d'Andrei Barinov.

Vos clips vidéo sont également trop longs. De 45 minutes, elles doivent être réduites à 5 minutes, ou mieux encore, à 3.

1. Oui, il s'avère que la définition d'"interprète" convient le mieux à ce que j'ai créé (bien que dans le processus de création je n'avais aucune idée de ce que c'est).

  • Oui, c'est vrai. L'interpréteur est créé sous forme de fichier texte. Plus précisément, une initialisation directe du tableau "string SOURCE[]" à l'intérieur du fichier connecté à l'indicateur est effectuée. (Le fichier de l'indicateur est ensuite compilé par l'utilisateur, et le contenu du tableau est transmis au constructeur (Expert Advisor) en utilisant la fonction EventChartCustom().

  • Dans le constructeur, l'adoption du "code KIB" de l'utilisateur sous forme de "découpage" de chaînes de caractères est effectuée. Chaque chaîne passée est une union de 128 caractères. Ces chaînes sont découpées en tranches et écrites dans une copie du tableau SOURCE du côté du concepteur. Ensuite, le "kernel building block" est exécuté, ce qui transforme le contenu du tableau "SOURCE" en contenu du tableau "int G_CORE[][]". C'est le "noyau". Le bloc convertit un contenu en un autre, plus de 5000 lignes de code (consiste en un ensemble de fonctions).
  • .
  • La conversion est effectuée à l'aide d'un tableau intermédiaire "int TEMPLATES[]", qui rassemble les prototypes de tous les éléments et de toutes les plates-formes de fenêtres. Suite à une instruction de "SOURCE[]" (créée par l'utilisateur), le noyau principal est assemblé. Les modèles d'éléments de "TEMPLATES" sont pris et transformés en "G_CORE".
  • .
  • Lorsque le noyau est construit, le "moteur" (la partie du constructeur responsable du contrôle des mécanismes de l'interface graphique) commence à travailler avec le noyau construit. Il dessine des kanvasses et ouvre des fenêtres.

2. Chaque fenêtre formée se compose de plusieurs kanvases (ressources). Les deux premiers sont des plateformes Windows. Auparavant, j'utilisais une méthode de dessin différente et, par conséquent, certaines parties étaient semi-transparentes et on pouvait voir le graphique à travers elles. Pour éviter cela, j'ai ajouté un autre kanvas en arrière-plan. Ensuite, la technique s'est améliorée, mais la toile reste à l'arrière-plan. Il s'est intégré à la technologie et il est difficile de s'en débarrasser maintenant. Mais je finirai par l'enlever et la plateforme de la fenêtre sera constituée d'une seule toile.

Aussi, les "champs" (onglets d'images commutables), sont des toiles indépendantes. Ils contiennent des images prêtes à l'emploi et permettent donc de basculer le plus rapidement possible. Si je devais tout dessiner sur un seul kanvas, le changement d'image serait inévitablement plus lent. Je devrais tout redessiner. Quoi qu'il en soit, après y avoir réfléchi, j'en suis arrivé à la conclusion que c'est la meilleure option.


3. Visual Constructor était, et est toujours, mon objectif. Je suis très proche du début de sa mise en œuvre. Il y a une compréhension de sa structure. Il existe tous les concepts nécessaires à sa mise en œuvre. Je sais comment le faire. Tout ce dont j'ai besoin, c'est de temps.


ZS. La particularité de mon développement est la spontanéité. Je n'étais pas familier avec les interprètes ou le langage HTML, et je ne savais pas comment ils fonctionnaient. Cependant, cela ne m'empêche pas de créer et de fabriquer des choses similaires. Je pense que si ça marche bien, je vais continuer à le faire. :)

 
Реter Konow:

À première vue, vous semblez avoir une utilisation très gaspilleuse de la mémoire. Je peux me tromper, cependant.

Idéalement, votre tâche ne devrait avoir qu'un seul canevas qui supporte la transparence sur le graphique des prix.

Les performances de MQL5 devraient être suffisantes pour former toute l'interface à la volée sans avoir de blocs prêts en mémoire, si le codage est correct.

Bien que je n'exclue pas la possibilité de sacrifier des ressources mémoire pour augmenter les performances d'interfaces encombrantes.

Je vois un grand avantage dans votre approche jusqu'à présent :

Il vous sera plus facile de créer un constructeur graphique à part entière, car il est plus facile de générer du code de balisage que le code MQL lui-même.


Mais c'est une tâche éléphantesque.
 
Nikolai Semko:

À première vue, vous semblez avoir une utilisation très gaspilleuse de la mémoire. Je peux me tromper, cependant.

Idéalement, votre tâche ne devrait avoir qu'un seul canevas qui supporte la transparence sur le graphique des prix.

Les performances de MQL5 devraient être suffisantes pour former toute l'interface à la volée sans avoir de blocs prêts en mémoire.

Bien que je n'exclue pas la possibilité de sacrifier des ressources mémoire pour augmenter les performances d'interfaces encombrantes.

Je vois un grand avantage dans votre approche jusqu'à présent :

Il sera plus facile pour vous de créer un constructeur graphique à part entière, car il est plus facile de générer du code de balisage, et non le code MQL lui-même.


Mais c'est une tâche éléphantesque.

Il y a toujours un dépassement de mémoire relativement faible. Vous avez raison. Les objets élémentaires tels que le texte ou l'icône se voient attribuer "sans le mériter" un nombre de 235 propriétés dans le noyau, alors que leurs propres propriétés sont plusieurs fois inférieures. L'objet principal de l'élément, à savoir la base, devrait avoir les 235 propriétés, mais les objets icône et texte ont moins de propriétés. Cela crée un dépassement de mémoire.

L'idée est que si j'ajoute 60 cellules supplémentaires à la rangée d'objets d'éléments principaux, je peux y placer des propriétés de texte et d'icône. Cela rendrait le noyau plus "large", mais vous pourriez supprimer deux tiers des objets.

Il y aurait d'excellentes économies de mémoire et un gain en vitesse de construction du noyau. Toutefois, cela est techniquement difficile à mettre en œuvre. Il y a beaucoup de travail à faire. Jusqu'à présent, la consommation de mémoire et le temps de construction sont tout à fait acceptables. Mais il n'y a pas de limite à la perfection...


Utiliser une seule toile n'est pas une bonne idée. Il est beaucoup plus facile d'utiliser un canevas pour chaque fenêtre et un canevas pour chaque champ. La toile générique doit être redessinée beaucoup plus souvent. Pour chaque changement d'image ou chaque changement de fenêtre. En défilant... Il faut tenir compte du fait que le redécoupage n'est pas toujours rapide. Le problème ne réside pas dans les algorithmes, mais dans la "sophistication" des graphiques. Laissez-moi vous expliquer :

Si vous dessinez une simple étiquette rectangulaire (un carré, par exemple), il s'agit d'un cycle sur un tableau de pixels avec les bonnes cellules initialisées avec la bonne valeur (couleur).

Si vous dessinez un carré avec un cadre, il s'agit de deux cycles sur un tableau de pixels.

Si vous dessinez un carré avec un cadre et une icône, il s'agit de trois cycles.

Si vous dessinez un carré avec un cadre qui a un dégradé de surface et une icône qui a une ombre, cela représente quatre cycles ou plus sur le tableau de pixels.

Ainsi, plus le graphique est pentu, plus il faut "repasser" cette matrice de pixels en cycles, pour créer la bonne image. Par conséquent, moins le besoin de redécoupage est important, mieux c'est.

Un seul canevas pour toutes les images, ce qui vous obligera à tout redessiner en permanence. Ce n'est donc pas une bonne solution.


ZS. La tâche est certes colossale, mais je peux la faire. (Même si je vais me faire aider.))

ZS. Merci pour la vidéo, c'est inspirant ! :)

 
Реter Konow:


Redimensionnez-vous la fenêtre avec la souris ?
Si oui, un carré rouge apparaît-il ?

 
Nikolai Semko:

Redimensionnez-vous la fenêtre avec la souris ?
Si oui, un carré rouge apparaît-il ?

Je ne comprends pas de quels carrés on parle.

La fenêtre dynamique peut être redimensionnée à l'aide de la souris. Comment pourrait-il en être autrement ?


ZS : La fenêtre dynamique a initialement une taille plein écran. En outre, il est "rogné" à la taille requise. En d'autres termes, tout son dynamisme est réalisé dans la taille maximale du bitmap déjà créé.

 

Pour continuer le sujet des arrondis.
J'ai découvert que les processeurs Intel modernes supportant le jeu d'instructions SSE4.1 étendu ont une commande d'arrondiROUND{PS, PD} . Je suis sûr qu'AMD a quelque chose de similaire.

https://ru.wikipedia.org/wiki/SSE4#SSE4a

http://o-ili-v.ru/wiki/SSE4

Cela signifie-t-il que le compilateur MQL5 n'utilise pas cette commande au niveau du CPU ? Puisque mon processeur Intel Kaby Lake supporte cet ensemble.

Et il y a bien d'autres choses, même la multiplication scalaire des vecteurs.

SSE4 — Википедия
  • ru.wikipedia.org
SSE4 — новый набор команд микроархитектуры Intel Core, впервые реализованный в процессорах серии Penryn (не следует путать с SSE4A от AMD)[1]. Он был анонсирован 27 сентября 2006 года, однако детальное описание стало доступно только весной 2007 года. Более подробное описание новых возможностей процессоров для программистов можно найти на сайте...
Raison: