Erreurs, bugs, questions - page 739

Nouveau commentaire
 
ivandurak:

Optimisez par champs de bits, il n'y aura pas de passages inutiles dans cette variante.

Par exemple :

input int bp=0;
int a=0;
int b=0;
Start()
{
 switch(bp)
   {
    case 0: a=0; b=0; break;
    case 1: a=0; b=1; break;
    case 2: a=1; b=0; break;
    default: a=1; b=1; break;    
   }
}

et optimiser dans les paramètres donnés, pour cet exemple bp est optimisé de 0 à 3

 
ivandurak:
Vous seul avez oublié d'écrire le verdict, que vous puissiez ou non.
Je n'ai rien oublié :) Si je savais exactement comment faire, je vous l'aurais dit. Il est un peu présomptueux de donner un verdict négatif, car ne pas connaître la solution ne signifie pas qu'il n'y en a pas.
 
Je comprends l'idée. Je me demande si la génétique va devenir folle avec un tel tour. Il s'avère qu'en principe, un ensemble de paramètres de travail donne un résultat nul et n'est pas impliqué dans la sélection ultérieure. Imho mieux dans les souhaits de methaquotes d'écrire quelque chose comme les paramètres optimisables liés, si elle est fausse, alors il ne devrait pas être exagéré.
 
Yedelkin:

Comment cela peut-il être "plus facile" ? :) Les conditions de suppression d'une EA ou de REASON_INITFAILED doivent encore être suivies. C'est ce qui ressemble à un tracas.

S'il n'y a pas de solution élégante, vous pouvez d'abord utiliser celle qui est la plus "facile". Trouvez quelque chose de mieux, vous pouvez toujours le remplacer. :)
 
ivandurak:
Il s'avère qu'en principe, un ensemble de paramètres de travail donne des résultats nuls et n'est pas impliqué dans la sélection ultérieure.
Pas vraiment, si on parle de mon idée de torture. Avec le "jeu de paramètres de travail" et la première passe trpar2=false, le résultat sera tout à fait fonctionnel. Toutes les passes suivantes avec le même "jeu de paramètres de travail" et trpar2=false retourneront immédiatement zéro, mais votre "jeu de paramètres de travail" participera quand même à la sélection et les passes dupliquées seront rejetées. C'est ce que tu voulais, n'est-ce pas ?
 
tol64:
En l'absence d'une solution élégante, vous pouvez d'abord utiliser la solution la plus "facile". Si l'on trouve quelque chose de mieux, on peut toujours le remplacer. :)
Une fois de plus : le problème n'est pas de savoir quelle commande permet de terminer la passe plus tôt - c'est une solution assez primitive, quelle qu'elle soit. Botanique - dans le suivi des conditions pour l'achèvement rapide du passage. Du fait que le passage sera achevé à l'avance avec l'aide de votre proposition, le "bloc de suivi" n'est pas diminué, et l'élégance de ce bloc n'est en rien augmentée.
 
Yedelkin:
Pas vraiment, si tu parles de mon idée de torture. Avec le "working set of parameters" et le premier trpar2=false la passe donnera un résultat tout à fait fonctionnel. Toutes les autres passes avec le même "jeu de paramètres de travail" et trpar2=false retourneront immédiatement zéro, mais votre "jeu de paramètres de travail" participera quand même à la sélection. C'est ce que tu voulais, n'est-ce pas ?

Vous pouvez le corriger un peu. Les paramètres d'optimisation doivent être écrits dans des structures, et celles-ci (structures simples) doivent être traitées comme des variables. Le code devrait être le suivant

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par ; Parold2=Par2 ; return(9) } Ici, Par et Parold sont des structures dans lesquelles sont inscrits les paramètres optimaux des autres paires de devises. Autant de paires que de si, ça n'a pas l'air si laid. Merci.

 
Yedelkin:
Encore une fois : le problème n'est pas de savoir quelle commande permet de mettre fin à la passe de manière anticipée - il s'agit d'une solution plutôt primitive, quelle qu'elle soit. La difficulté réside dans le suivi des conditions d'achèvement anticipé du col. Le fait que le passage sera achevé à l'avance avec l'aide de votre suggestion, "l'unité de suivi" elle-même n'est pas moins gênante et l'élégance de cette unité n'est pas augmentée en aucune façon.

Qu'est-ce que tu voulais dire par là ? Qu'en l'absence d'une solution élégante, il ne faut pas en utiliser du tout ? Même s'il y en a un, mais, comme vous le dites, "douloureux" ?

En bref, allons de l'avant. Sinon, c'est plus gênant du point de vue de l'inondation que du code. :)

 
ivandurak:

Vous pouvez le corriger un peu. Les paramètres d'optimisation doivent être écrits dans des structures, et celles-ci (structures simples) doivent être traitées comme des variables. Le code devrait être le suivant

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par ; Parold2=Par2 ; return(9) } Ici, Par et Parold sont des structures dans lesquelles sont inscrits les paramètres optimaux des autres paires de devises.

Oui, quelque chose comme ça. Il s'avère simplement que nous devrons nous souvenir de TOUS les "ensembles de paramètres de travail" qui sont entrés en collision avec trpar2=false. C'est-à-dire que l'éventail des structures correspondantes s'élargirait considérablement. En outre, il devra être sauvegardé dans un fichier pour être lu en mémoire lors d'un nouveau passage.
 
ivandurak:

Vous pouvez le corriger un peu. Les paramètres d'optimisation doivent être écrits dans des structures, et celles-ci (structures simples) doivent être traitées comme des variables. Le code devrait être le suivant

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par ; Parold2=Par2 ; return(9) } Ici, Par et Parold sont des structures dans lesquelles sont inscrits les paramètres optimaux des autres paires de devises. Autant de paires que de si, ça n'a pas l'air si laid. Merci.

Il existe une autre variante (qui m'a échappé).

Vous pouvez jeter un coup d'œil aux fonctions : OnTesterInit(), OnTesterPass(), OnTesterDeinit().

Et FrameFirst (),FrameFilter (),FrameNext (),FrameInputs (),FrameAdd().

C'est exactement ce à quoi ils servent. :)

C'est-à-dire que vous pouvez toujours demander tous les paramètres de n'importe quelle passe dans l'optimisation actuelle à tout moment.

1...732733734735736737738739740741742743744745746...3184
Nouveau commentaire
Raison: