Arbres dynamiques C # pour la programmation génétique

c# expression-trees genetic-programming

Question

J'ai des classes définies par l'utilisateur public avec des relations entre leurs membres et plusieurs méthodes avec des signatures spécifiques et génériques.

J'aimerais pouvoir stocker et manipuler un flux de contrôle personnalisé sur ces classes (plus des classes CLR) à l'aide d'instructions de contrôle de base telles que if / then / else, foreach, do / while, affectations de variables, etc.

Le flux de contrôle personnalisé doit être créé au moment de l'exécution, puis stocké pour une utilisation et une manipulation ultérieures. L'idée est de disposer d'une représentation des données du flux de contrôle, éventuellement sous la forme d'un arbre de syntaxe abstraite, avec une syntaxe fortement typée afin de pouvoir appliquer des opérations génétiques. Le code personnalisé résultant doit être exécuté dans le cadre d'un autre programme.

1) Quelle est la représentation de code préférée pour manipuler des opérations génétiques et ensuite exécuter le code incluant mes classes,

2) Quelles technologies c # dois-je utiliser pour résoudre le problème ci-dessus? Je sais qu'il existe des technologies connexes telles que la réflexion, les nouvelles fonctionnalités c # 3.0 (lambda, arbres d'expression), CodeDom, la bibliothèque DLR, etc., mais quelle approche ou combinaison est la plus efficace.

3) Existe-t-il de tels paradigmes ou implémentations?

EDIT: La plate-forme reçoit des données de types personnalisés c # définis, variables constantes et variables dans le temps.

À chaque instant, des règles sont appliquées aux données (conditions de base ou fonctions plus complexes) et il est décidé de prendre des mesures.

J'aimerais pouvoir:

Représentez les règles sur un arbre ou un graphique et exécutez ce flux.

Créer des jeux de règles personnalisés par l'utilisateur via un toolkit d'interface utilisateur

Réarrangez l’arbre ou le graphique et appliquez les opérations de GP.

Réponse acceptée

Reflection est la technologie permettant d'inspecter les types, méthodes, champs, etc. déjà générés. Par conséquent, cela ne vous aidera probablement pas beaucoup pour l'instant.

Les arbres d'expression sont plutôt intéressants, mais autant que je sache, ils ne vous permettent pas de créer un flux de programme complexe, car une expression lambda ne peut pas avoir de corps, ce qui rendrait plutôt difficile la création d'un objet moyennement complexe.

Le DLR est un peu en devenir. Vous obtiendrez les éléments de base, mais seule la prochaine version .NET prendra en charge de manière intégrée le DLR. Cela pourrait être une alternative intéressante, en créant des programmes à la volée et en les exécutant.

Ce que vous pourriez faire maintenant, c'est éventuellement émettre IL, soit dans une méthode dynamique, soit dans un assemblage généré dynamiquement. Toutes les constructions possibles devraient être disponibles, mais une manipulation ultérieure est probablement assez difficile.

Néanmoins, il existe un projet qui fait un peu de magie IL et pourrait même vous être utile: LinFu . Selon la liste, vous avez une implémentation de Dynamic Object et pouvez effectuer des tâches telles que dynamicObject.CreateDuck <InterfaceType> ()

Le framework WF (Workflow Foundation) est une autre voie un peu lourde mais intéressante. De tels flux de travail doivent pouvoir être construits par programme et peuvent être intéressants en raison de leur style de continuation: Vous pouvez conserver un flux de travail en cours à tout moment et le reprendre à l'endroit où vous l'avez laissé.

Toutes les structures de programme traditionnelles doivent être à votre disposition au sein de WF.


Réponse populaire

Il vous suffit de générer c # (de n’importe quel autre langage .net prenant en charge cette fonctionnalité, f # fonctionne également très bien) et d’utiliser CodeDomProvider pour le compiler à la volée. Forcer le code fourni à être un fichier source, pour inclure un type qui implémente IDynamicEntryPoint (avec une méthode statique ou un constructeur vide qui est le point d’entrée et qui sera appelé après la construction)

Cela devrait être votre première escale pour commencer car il est rapide d'essayer en même temps d'avoir les meilleures chances d'obtenir les meilleures performances à long terme (à moins d'une sortie IL dynamique mais vous ne pourriez même pas battre le compilateur)

Cela a évidemment deux défauts possibles qui peuvent être des briseurs d’affaires:

  • Le code qui en résulte est un cauchemar de sécurité. Seule la saisie de code par des utilisateurs de confiance doit être autorisée.
  • Le code compilé dynamiquement est fragile en ce qui concerne les modifications de code / d'interface (l'ensemble des dll que le code doit inclure peut-être changé / peut ne pas correspondre) ou la signature de IDynamicEntryPoint peut être modifiée.

À moins que vous ne souhaitiez écrire votre propre langage / analyseur / compilateur pour le plaisir, utilisez-en un qui existe déjà.




Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi