Représentation d'un objet en programmation. - page 17

Nouveau commentaire
 
transcendreamer #:

72 cas, 24 nouveaux cas spéciaux, un système d'écriture non linéaire, une grammaire matricielle, une morphosyntaxe, un boustrophédon et une phonétique spéciale - exactement ce dont les sectes commerciales les plus cool ont besoin (pour que les Tchékistes et les Francs-maçons ne puissent pas voler le Graal).

Oui, il faut absolument traduire l'expression "croisement de deux moyennes mobiles" en Ifkuil).

 

En raison du fait que le sujet de ce thème est largement philosophique et ne s'inscrit pas seulement dans les limites de l'algotraining, mais aussi (dans certains endroits) de la programmation en général, j'ai décidé de compléter la série de parties du concept par une dernière théorie de "l'algorithme de complication", en exposant sa compréhension et en répondant à la question - un tel algorithme peut-il exister en principe ?

Comme prévu, nous allons considérerle "mécanisme de complication" sur l'exemple d'un simple marqueur rectangulaire sur l'écran de pixels, dessiné en appelant une fonction graphique composée de deux boucles imbriquées (hauteur et largeur) et utilisant 5 paramètres de base - x, y, largeur, hauteur, couleur.

Nous appellerons la fonction de dessin le "constructeur" et son jeu de paramètres l'objet. Il convient de noter que, pour la plupart des gens,un objet est un "sous-ensemble" de pixels séparés par une couleur et combinés géométriquement en un ensemble commun de pixels de l'écran, mais pour le programmeur, un objet n'est pas seulement une forme externe, perçue par l'œil, mais aussi la création du mécanisme lui-même. Une étiquette, comme nous le savons, est "construite" en deux cycles par la fonction de dessin, ce qui signifie que la fonction avec ses paramètres est également une "étiquette". Ce point est difficile à réaliser, car la personne est habituée à la perception visuelle d'une coquille d'objet et considère le code qui se cache derrière comme quelque chose de farfelu et de secondaire, cependant - c'est l'objet lui-même, après tout, en cas de changement de la mise en œuvre de la fonction initiale ou des valeurs de ses paramètres, le changement externe d'une coquille suit inévitablement.

Je trouve plus facile de séparer le jeu de paramètres d'une fonction de son implémentation interne et de le traiter comme l'objet principal, bien que ce ne soit évidemment pas vrai, car l'implémentation interne de la fonction constructeur et son jeu de paramètres sont inextricablement liés. Cependant, l'implémentation interne change beaucoup moins fréquemment et ces changements sont plus fondamentaux que, par exemple, des changements dans les valeurs de l'ensemble paramétrique, qui sont faciles à travailler et à expérimenter. Si la méthode de mise en œuvre de la fonction constructeur change, un nouvel ensemble de paramètres apparaît, ce qui entraîne des modifications de tous les "proto-blocs" construits sur la base de l'ancien ensemble de paramètres de la fonction constructeur. I.e. si nous avons initialement construit un état alternatif de l'étiquette avec 5 paramètres :x, y, largeur, hauteur, couleur avec des valeurs différentes et que nous l'avons ensuite "activé" lors d'un événement, alors un changement inattendu de la méthode d'implémentation du constructeur de fonctions, qui réduit le nombre de paramètres, disons, à 3, changera la structure de l'ensemble paramétrique primaire (à partir duquel d'autres états, événements ou processus ont probablement déjà été créés) et la construction précédente de l'état alternatif de l'étiquette "s'effondrera", devenant inutile pour la nouvelle version du constructeur de fonctions. Nous sommes ici confrontés au premier obstacle majeur de la mise en œuvre de l'algorithme de complication : la méthode de mise en œuvre de la fonction-constructeur fixe des limites au potentiel de complication de l'objet. Transcender ces frontières sans intervention humaine, selon un algorithme quelconque, est une complication automatisée.

Considérons une complication expérimentale "simple" d'une étiquette sans changer la méthode originale de sa mise en œuvre de fonction-constructeur et sans entrer dans le sens de la complication - nous allons seulement changer les valeurs de son jeu de paramètres et "débrancher" de nouveaux états sur sa base et voir ce que nous obtenons :

  • Nous sélectionnons un ensemble de paramètres pour un nouvel état à partir de l'ensemble initial des paramètres du constructeur de fonctions, nous inventons de nouvelles valeurs pour ces paramètres et nous les écrivons dans le bloc de mémoire alloué.
  • Avec un seul état supplémentaire d'une étiquette, nous rencontrons automatiquement le besoin de construire un modèle d'événement, car si une étiquette a au moins UN autre état, elle doit à un moment donné y passer, et nous devons donc décrire un événement associé à l'environnement ou à un autre objet qui fera passer l'étiquette dans un autre état. En d'autres termes, un état nouvellement ajouté nécessite logiquement au moins une description d'événement pour passer à un autre état et (éventuellement) une deuxième description d'événement pour revenir à l'état initial ou à un autre état.
  • D'où une thèse simple : chaque ajout d'un nouvel état à l'objet entraîne l'ajout d'au moins un, et de préférence deux nouveaux événements, dont la description doit être placée dans les conditions du modèle d'événement, qui, comme nous le savons, est une sorte de "mécanisme de communication" de l'objet et de l'environnement et décrit leur interaction par sa logique. A priori, seule la présence de SM peut faire basculer l'Objet entre les états. Conclusion :+ 1 État de l'objet = +2 Événements de l'objet ou de l'environnement + 2 conditions SM.
  • L'ajout d'états d'objet entraîne l'ajout d'événements de changement d'état d'objet et il devient nécessaire de hiérarchiser les nouveaux événements, et la structure hiérarchique est la mieux adaptée pour cela. Simultanément à l'apparition de nouveaux événements et états, l'arbre des conditions se développe. Le comportement de l'Objet est enrichi par une variété de réactions aux interactions externes avec les choses "impliquées" dans sa vie et il faut dire que plus la complexité est grande, plus le contact externe est large. Il s'avère que nous ne pouvons pas considérer la complication de l'étiquette isolément de son environnement et que nous avons besoin de l'environnement d'interaction, sinon les nouveaux états deviendront un "poids mort" en mémoire et le seul événement possible de leur changement sera le minuteur interne.
  • Nous avons constaté que cela n'a pas de sens de créer les états du nouvel Objet sans événements les reliant de manière inséparable aux objets de l'environnement, tout comme cela n'a pas de sens d'ajouter des événements en dehors du Modèle d'événements les reliant aux états et aux processus de l'Objet.Dans le processus de complexification de l'Objet, il est nécessaire de tout ajouter en même temps - États, Événements, conditions du Modèle d'événements (en l'organisant en ordre hiérarchique simultanément) et de créer la relation Événement->État ou... Événement->Processus, etc.
  • L'ajout d'un processus objet n'est pas fondamentalement différent de l'ajout d'un état et la seule différence est la quantité de mémoire à allouer. Le nouveau processus, tout comme l'état, nécessite la définition d'événements de base pour lui-même, tels que : événements de démarrage, événements de commutation, événements d'arrêt...


Conclusion :

Il est certain qu'il serait nécessaire d'écrire plus d'un livre et qu'un post ne suffira pas, mais il est déjà évident que si nous définissons l'objectif de la complication d'un programme, de sorte qu'il crée des modèles d'objets avec différents états, événements, réactions à l'environnement, même sans changer la mise en œuvre d'un concepteur de fonctions et en s'appuyant sur un ensemble de paramètres fixes, probablement, après une nième quantité d'essais et d'erreurs, il pourrait créer une étiquette exécutant une tâche simple, mais ce programme devrait "être capable" de construire des "proto-blocs" - états, événements, Je suis optimiste, même si je peux imaginer la complexité d'une telle tâche.

 
Bonjour à tous, j'ai un conseiller expert, il a besoin de plus de travail, je teste environ 100 $ par jour sur eurusd et usdchf.
 
Ruslan #:
Bonjour à tous j'ai un conseiller expert j'ai besoin de plus de détails si quelqu'un est bon à cela maintenant je teste environ 100$ par jour sur eurusd et usdchf.

va...

les objets qu'il contient sont mal représentés :-)

PS/ garantie d'échec, quels que soient les objets

 
Bonjour les gars, pouvez-vous s'il vous plaît corriger ceci ;les expressions ne sont pas autorisées sur une portée globale strategy("DailyCandleCross", shorttitle="DCC", overlay=true, calc_on_order_fills= true, calc_on_every_tick=true, default_qty_type=strategy.percent_of_equity, default_qty_value=75, pyramiding=0)
 
Je veux révéler mes propres illusions et celles d'autres personnes (si j'ai contribué à leur apparition sans le vouloir) concernant le soi-disant "algorithme de la complication" et ramener les lecteurs enthousiastes à la dure réalité, où l'univers lui-même nie toute forme et toute variation du"graal" et montrer que mon raisonnement est le produit d'un esprit enflammé par l'amour de la philosophie et les nuits blanches à inventer le "perpetuum mobile" ou la "machine à remonter le temps", souffrant de la croyance en son propre génie.
L'algorithme de complication ne peut pas être mis en œuvre, ou plus exactement, sa version "idiote" peut être mise en œuvre, où un programme quelconque estampille au hasard des états paramétriques, des événements, des processus et des conditions d'un certain objet, puis, dans le même hasard, les compose les uns avec les autres et... les efface et recommence. Cette action étrange peut durer éternellement et son objectif n'est absolument pas clair. Quel est le résultat ? Un résultat aléatoire ? Et vous vous souvenez du problème avec la fonction constructeur ? Comment modifier sa mise en œuvre ? Ce n'est pas clair du tout... Le problème est que le moindre changement dans la méthode de mise en œuvre détruit complètement la "légitimité" de toutes les structures proto-blocs, les rendant inutilisables par la fonction modifiée. En somme, c'est une tâche qui prendra des années, en supposant qu'elle sera résolue par l'Institut de recherche ou l'Académie des sciences, et non le fait qu'en fin de compte quelque chose fonctionnera.
L'atmosphère de ce forum est saturée d'inspiration graal et crée un état d'esprit approprié, à partir duquel ce dernier génère des paraboles étonnantes, proches de la science, qui, malheureusement, ne mènent jamais à quelque chose de pratique, bien que... ...bien que ce soit énergisant. :)
Ne jugez pas trop sévèrement, j'étais juste sur un "coup de pied philosophique"))))
 
Merde, c'est encore l'escalade ? C'est devenu silencieux.
 
Реter Konow "graal", et montrer que mon raisonnement est un produit de l'esprit enflammé par l'amour de la philosophie, qui passe des nuits blanches à inventer le "perpetuum mobile" ou la "machine à remonter le temps", en ayant foi en son propre génie.
L'algorithme de complication ne peut pas être mis en œuvre, ou plus exactement, sa version "idiote" peut être mise en œuvre, où un programme quelconque estampille au hasard des états paramétriques, des événements, des processus et des conditions d'un certain objet, puis, dans le même hasard, les compose les uns avec les autres et... les efface et recommence. Cette action étrange pourrait durer éternellement et son objectif n'est absolument pas clair. Quel est le résultat ? Un résultat aléatoire ? Et vous vous souvenez du problème avec la fonction constructeur ? Comment modifier sa mise en œuvre ? Ce n'est pas clair du tout... Le problème est que le moindre changement dans la méthode de mise en œuvre détruit complètement la "légitimité" de toutes les structures proto-blocs, les rendant inutilisables par la fonction modifiée. En somme, c'est une tâche qui prendra des années, en supposant qu'elle sera résolue par l'Institut de recherche ou l'Académie des sciences, et non le fait qu'en fin de compte quelque chose fonctionnera.
L'atmosphère de ce forum est saturée d'inspiration graal et crée un état d'esprit approprié, à partir duquel ce dernier génère des paraboles étonnantes, proches de la science, qui, malheureusement, ne mènent jamais à quelque chose de pratique, bien que... ...bien que ce soit énergisant. :)
Ne jugez pas trop sévèrement, j'étais juste dans un "coup de poing philosophique" ;)))

Si vous vous trouvez soudainement dans un état d'esprit cognitif, lisez sur la programmation génétique (spoiler : vous ne pouvez pas faire sans Bacus-Naurus).

1...1011121314151617
Nouveau commentaire
Raison: