Fehler, Irrtümer, Fragen - Seite 739

Neuer Kommentar
 
ivandurak:

Optimieren nach Bitfeldern, bei dieser Variante gibt es keine unnötigen Durchläufe.

Zum Beispiel:

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;    
   }
}

und optimieren Sie in den vorgegebenen Parametern, in diesem Beispiel wird bp von 0 bis 3 optimiert

 
ivandurak:
Sie haben nur vergessen, das Urteil zu schreiben, ob Sie es können oder nicht.
Ich habe nichts vergessen :) Wenn ich genau wüsste, wie es geht, hätte ich es Ihnen gesagt. Es ist ein bisschen anmaßend, ein negatives Urteil zu fällen, denn die Lösung nicht zu kennen, bedeutet nicht, dass es keine Lösung gibt.
 
Ich verstehe die Idee. Ich frage mich, ob die Genetik von so einem Trick verrückt wird. Es stellt sich heraus, dass eine Arbeitsgruppe von Parametern im Prinzip ein Null-Ergebnis liefert und nicht in die weitere Auswahl einbezogen wird. Imho besser in den Wünschen der methaqvoters schreiben etwas wie verwandte optimierbare Parameter, wenn es falsch ist, dann sollte es nicht überschrieben werden.
 
Yedelkin:

Wie kann es "einfacher" sein? :) Die Bedingungen für das Löschen eines EA oder für REASON_INITFAILED müssen noch verfolgt werden. Das sieht nach Ärger aus.

Wenn es keine elegante Lösung gibt, können Sie zunächst die "einfachere" Lösung wählen. Finden Sie etwas Besseres, Sie können es jederzeit ersetzen. :)
 
ivandurak:
Es stellt sich heraus, dass eine Arbeitsgruppe von Parametern im Prinzip keine Ergebnisse liefert und nicht in die weitere Auswahl einbezogen wird.
Nicht wirklich, wenn es um meine quälende Idee geht. Mit "working set of parameters" und dem ersten trpar2=false-Durchgang wird ein recht gutes Ergebnis erzielt. Alle nachfolgenden Durchläufe mit demselben "Arbeitsparametersatz" und trpar2=false geben sofort Null zurück, aber Ihr "Arbeitsparametersatz" nimmt trotzdem an der Auswahl teil und doppelte Durchläufe werden abgelehnt. Das ist es doch, was du wolltest, oder?
 
tol64:
In Ermangelung einer eleganten Lösung können Sie zunächst die "einfachere" Lösung verwenden. Wenn etwas Besseres gefunden wird, kann es jederzeit ersetzt werden. :)
Noch einmal: Das Problem ist nicht, welcher Befehl den Durchgang vorzeitig beendet - es ist eine ziemlich primitive Lösung, was auch immer es ist. Beidhändigkeit - bei der Verfolgung der Bedingungen für die vorzeitige Vollendung der Passage. Dadurch, dass die Passage mit Hilfe Ihres Vorschlags vorzeitig abgeschlossen wird, wird der "Tracking-Block" nicht verringert, und die Eleganz dieses Blocks wird in keiner Weise erhöht.
 
Yedelkin:
Nicht wirklich, wenn Sie von meiner quälenden Idee sprechen. Mit "working set of parameters" und dem ersten trpar2=false wird der Durchlauf ein recht gutes Ergebnis liefern. Alle anderen Durchläufe mit demselben "Arbeitsparametersatz" und trpar2=false führen sofort zu Nullen, aber Ihr "Arbeitsparametersatz" wird trotzdem an der Auswahl teilnehmen. Das ist es doch, was du wolltest, oder?

Sie können es ein wenig korrigieren. Die Optimierungsparameter sollten in Strukturen geschrieben werden, und diese (einfachen Strukturen) sollten als Variablen behandelt werden. Der Code sollte lauten

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Hier sind Par und Parold Strukturen, in die optimale Parameter von anderen Währungspaaren geschrieben werden. So viele Paare wie es Wenns gibt, sieht es nicht so hässlich aus. Ich danke Ihnen.

 
Yedelkin:
Noch einmal: Es geht nicht darum, mit welchem Befehl der Durchgang vorzeitig beendet werden soll - das ist eine ziemlich primitive Lösung, was auch immer das sein mag. Die Schwierigkeit besteht darin, die Bedingungen für die vorzeitige Beendigung des Passes im Auge zu behalten. Die Tatsache, dass die Passage mit Hilfe Ihres Vorschlags vorzeitig abgeschlossen wird, macht die "Tracking-Einheit" selbst nicht weniger lästig, und die Eleganz dieser Einheit wird in keiner Weise erhöht.

Was haben Sie damit gemeint? Dass man in Ermangelung einer eleganten Lösung überhaupt keine verwenden sollte? Selbst wenn es eine gibt, aber, wie Sie es ausdrücken, "schmerzhaft"?

Kurzum, lassen Sie uns weitermachen. Ansonsten ist die Überflutung lästiger als der Code. :)

 
ivandurak:

Sie können es ein wenig korrigieren. Die Optimierungsparameter sollten in Strukturen geschrieben werden, und diese (einfachen Strukturen) sollten als Variablen behandelt werden. Der Code sollte lauten

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Hier sind Par und Parold Strukturen, in die optimale Parameter von anderen Währungspaaren geschrieben werden.

Ja, so ähnlich. Es stellt sich nur heraus, dass wir uns ALLE "Arbeits-Parametersätze" merken müssen, die mit trpar2=false kollidierten. D.h. die Palette der entsprechenden Strukturen würde sich immens erweitern. Außerdem muss sie in einer Datei gespeichert werden, damit sie bei einem neuen Durchgang wieder gelesen werden kann.
 
ivandurak:

Sie können es ein wenig korrigieren. Die Optimierungsparameter sollten in Strukturen geschrieben werden, und diese (einfachen Strukturen) sollten als Variablen behandelt werden. Der Code sollte lauten

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Hier sind Par und Parold Strukturen, in die optimale Parameter von anderen Währungspaaren geschrieben werden. So viele Paare wie es Wenns gibt, sieht es nicht so hässlich aus. Ich danke Ihnen.

Es gibt noch eine weitere Variante (die mir entfallen ist).

Sie können sich die Funktionen ansehen: OnTesterInit(), OnTesterPass(), OnTesterDeinit().

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

Das ist genau das, wofür sie da sind. :)

Das heißt, Sie können jederzeit alle Parameter eines beliebigen Durchgangs der aktuellen Optimierung abfragen.

1...732733734735736737738739740741742743744745746...3184
Neuer Kommentar