Mein MATLAB Forum - goMatlab.de

Mein MATLAB Forum

 
Gast > Registrieren       Autologin?   

Bücher:

MATLAB und Mathematik kompetent einsetzen

Fachkräfte:
weitere Angebote

Partner:


Vermarktungspartner


Forum
      Option
[Erweitert]
  • Diese Seite per Mail weiterempfehlen
     


Gehe zu:  
Neues Thema eröffnen Neue Antwort erstellen

Optimization Toolbox - fmincon findet seltsames Minimum

 

Chris_Kiel
Forum-Newbie

Forum-Newbie


Beiträge: 8
Anmeldedatum: 05.01.21
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 05.01.2021, 23:45     Titel: Optimization Toolbox - fmincon findet seltsames Minimum
  Antworten mit Zitat      
Hallo, ich versuche, eine Funktion mit fmincon zu minimieren. Zur Kontrolle lasse ich mir bei jedem Aufruf der Funktion ausdrucken, mit welchen Parametern sie aufgerufen wurde, und welchen Wert sie retournieren wird. Und dabei ist mir folgendes aufgefallen: fmincon "findet" ein Minimum, das nicht ideal ist. Es mag ein lokales Minimum sein, und mir ist bewusst, dass fmincon nicht unbedingt das globale Minimum findet... aber wie kann es sein, dass es bei der Suche nach dem Minimum schon über andere Stellen gelaufen ist, bei denen die Funktion kleinere Werte retourniert hat? Ich kann mir vorstellen, dass fmincon in einem lokalen Minimum hängen bleibt und daher ein globales Minimum verpasst... aber wenn fmincon schon über eine Stelle mit einem niedrigeren Wert gelaufen ist, dann sollte das doch eigentlich nicht mehr passieren, oder?

Gibt es Routinen (in der Optimization Toolbox... die Global Optimization Toolbox habe ich nicht), die zumindest berücksichtigen, wenn sie "zufällig" über tiefere Stellen der Funktion hinweglaufen?

Vielen Dank im voraus
Chris (aus Kiel)
Private Nachricht senden Benutzer-Profile anzeigen


Harald
Forum-Meister

Forum-Meister


Beiträge: 22.729
Anmeldedatum: 26.03.09
Wohnort: Nähe München
Version: ab 2017b
     Beitrag Verfasst am: 06.01.2021, 00:01     Titel:
  Antworten mit Zitat      
Hallo,

ist mit den gegebenen Informationen schwer nachzuvollziehen. Eine Möglichkeit wäre, dass bei dem niedrigen Zielfunktionswert eine der Nebenbedingungen nicht erfüllt war.

Je mehr Details du zur Verfügung stellen kannst, desto besser...

Grüße,
Harald
_________________

1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Private Nachricht senden Benutzer-Profile anzeigen
 
Chris_Kiel
Themenstarter

Forum-Newbie

Forum-Newbie


Beiträge: 8
Anmeldedatum: 05.01.21
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 06.01.2021, 09:27     Titel:
  Antworten mit Zitat      
Hallo Harald,

ok, ich will mich in Details versuchen Smile Wir versuchen, ein probabilistisches Modell an reale Versuchsergebnisse mit einem maximum-likelihood Algorithmus anzupassen. Das Modell hat sieben Parameter, hier zitiere ich mal (keine Ahnung, ob das hilft) die Startwerte und die lower und upper bounds

Code:

x0 = [0.02,  62,     1.5,    0.6,   0.05,   0.5,  0.5];
lb = [0.01,  60,     0.0,    0.0,   0.0,    0.0,  0.0];
ub = [5,     72,     5.0,    1.0,   1.0,    1.0,  1.0];
 


Das Modell ist halbwegs kompliziert, es hat viele Fallunterscheidungen, weshalb ein einzelner Aufruf in etwa eine halbe Sekunde kostet. Es liefert eine Matrix (12x12) von Wahrscheinlichkeitswerten, und die reellen Daten sind ebenfalls eine Matrix (12x12) von Fallzahlen (wie oft wurde in einem bestimmten Feld der Matrix eine von zwei möglichen Antworten gegeben), und daraus kann man eben die Wahrscheinlichkeit für diesen Versuchsablauf (gegeben die vom Modell errechneten Wahrscheinlichkeiten) errechnen. Die ist irre klein, der negative Logarithmus ist eine positive dreistellige Zahl (ich berechne den negativen Logarithmus, weil fmincon ja ein Minimum sucht), aber das ist normal, weil ja die Wahrscheinlichkeit, dass das Experiment mit seinen vielen Einzelversuchen genau so ausgegangen wäre, berechnet wird. Es gilt, dasjenige Modell zu finden, das bei all diesen irre kleinen Wahrscheinlichkeiten dann doch die größte Wahrscheinlichkeit für die Versuchsergebnisse vorhersagt (maximum likelihood).

Ich lasse mir bei jedem Aufruf der Funktion "loglike" (der negative Logarithmus der Wahrscheinlichkeit) folgende Werte ausdrucken:
    der wievielte Aufruf ist es,
    wie viele Sekunden sind seit Start vergangen,
    wie hoch ist der Wert LL (loglike) der minimiert werden soll,
    eine Streuung über die letzten 10 Werte von LL,
    und dann die sieben Parameter.

Das sieht zum Beispiel irgendwann zwischendurch so aus:

Code:

309 (124.51 s): LL = 1948.018 +- 5.395, P = 0.0536 62.0014 1.3125 0.5983 0.0481 0.4596 0.5000
310 (124.89 s): LL = 1948.018 +- 5.212, P = 0.0536 62.0014 1.3125 0.5983 0.0481 0.4596 0.5000
311 (125.28 s): LL = 1948.018 +- 4.825, P = 0.0536 62.0014 1.3125 0.5983 0.0481 0.4596 0.5000
 


da denkt man, er hat es geschafft, denn LL=1948 ist ein günstiger Wert. Dann probiert er anscheinend auch wieder ungünstigere Sachen aus

Code:

312 (125.64 s): LL = 2716.323 +- 231.067, P = 4.9753 61.9603 0.1125 0.4520 0.0910 0.0915 0.5000
 


findet zurück zur günstigen Stelle

Code:

313 (126.03 s): LL = 1948.018 +- 231.362, P = 0.0536 62.0014 1.3125 0.5983 0.0481 0.4596 0.5000
 


um wenig später zunächst noch einmal ein paar ungünstige Ausflüge zu machen, und sich dann eine andere, "halb-günstige" Stelle auszusuchen:

Code:

320 (128.99 s): LL = 1948.018 +- 231.653, P = 0.0536 62.0014 1.3125 0.5983 0.0481 0.4596 0.5000
321 (129.35 s): LL = 2716.324 +- 310.795, P = 4.9753 61.9603 0.1125 0.4520 0.0910 0.0915 0.5000
322 (129.71 s): LL = 2627.816 +- 345.850, P = 2.5144 61.9808 0.7125 0.5251 0.0696 0.2755 0.5000
323 (130.09 s): LL = 2453.929 +- 310.042, P = 1.2840 61.9911 1.0125 0.5617 0.0589 0.3676 0.5000
324 (130.47 s): LL = 2164.902 +- 304.461, P = 0.6688 61.9963 1.1625 0.5800 0.0535 0.4136 0.5000
325 (130.84 s): LL = 1958.348 +- 303.807, P = 0.0536 62.0014 1.3125 0.5983 0.0481 0.4596 0.5000
 


und obwohl er schon bei 1948 war, gefällt ihm 1958 besser: er endet wie folgt:

Code:

330 (132.78 s): LL = 1958.348 +- 300.465, P = 0.0536 62.0014 1.3125 0.5983 0.0481 0.4596 0.5000

Local minimum possible. Constraints satisfied.

fmincon stopped because the size of the current step is less than
the value of the step size tolerance and constraints are
satisfied to within the value of the constraint tolerance.

<stopping criteria details>

param =

    0.0536   62.0014    1.3125    0.5983    0.0481    0.4596    0.5000

 


Ich kann ja verstehen, dass ein Minimierer in einem lokalen Minimum hängen bleibt... aber auch, nachdem er zuvor schon tiefere Stellen durchforstet hat?

Gäbe es andere Optimierer in der Optimization Toolbox, denen so etwas nicht passieren würde? Oder ist meine Fragestellung eben einfach eine für die Global Optimization Toolbox, die mich 200 Euro kosten würde (was ich durchaus im Budget habe, aber wenn es ein einfacher Fehler ist, muss ich die ja nicht unbedingt ausgeben)?

Vielen Dank für jeden Rat
und beste Grüße aus Kiel
Chris
Private Nachricht senden Benutzer-Profile anzeigen
 
Harald
Forum-Meister

Forum-Meister


Beiträge: 22.729
Anmeldedatum: 26.03.09
Wohnort: Nähe München
Version: ab 2017b
     Beitrag Verfasst am: 06.01.2021, 09:42     Titel:
  Antworten mit Zitat      
Hallo,

wenn möglich, stelle bitte das reproduzierbare Beispiel zur Verfügung.

Weitere Fragen, die du selbst untersuchen kannst bzw. die ich mir ansehen würde, wenn ich den kompletten Code hätte:
* Ist die Zielfunktion deterministisch, d.h. kommt bei wiederholter Auswertung mit gleichem Input der gleiche Output heraus?
* Ist die Zielfunktion glatt? Ist es zumindest sinnvoll, Gradienten anzunähern?
* Gibt es lineare oder nichtlineare Nebenbedingungen? Falls ja, sind sie denn bei den guten Zielfunktionswerten erfüllt?
* Wie sieht der iterative Output aus, den fmincon produziert?

Grüße,
Harald
_________________

1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Private Nachricht senden Benutzer-Profile anzeigen
 
Chris_Kiel
Themenstarter

Forum-Newbie

Forum-Newbie


Beiträge: 8
Anmeldedatum: 05.01.21
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 06.01.2021, 12:54     Titel:
  Antworten mit Zitat      
Hallo Harald,

das ist ein sehr nettes Angebot. Gerne stelle ich den Code zur Verfügung. Hoffentlich vergesse ich nichts...

Man braucht

    - optimize_vp.m, die Hauptroutine
    - loglike.m, die zu minimierende Funktion
    - octave_pdata.m, das Modell, mit sieben Parametern
    - getoctave.m, eine Hilfsfunktion fürs Modell
    - und in einem Unter-Unterordner xls/exp eine Excel-Datei, hewif.xlsx


Um das zu vereinfachen, habe ich diese fünf Dateien inkl. Ordner-Struktur mal in eine Zip-Datei verpackt. Ich habe es gerade ausprobiert: dieser Ordner müsste alles notwendige enthalten, denn es läuft in diesem Ordner. Der Aufruf ist:

Code:

param = optimize_vp('hewif')
 


Und nun zu Deinen Fragen:
* Ja, die Zielfunktion ist deterministisch
* Ist sie glatt? Ich hoffe. Aber wie will ich das bei sieben Parametern kontrollieren? Sagen wir so: ich wüsste keinen Grund, warum sie nicht glatt sein sollte.
* Die Randbedingungen bestehen einfach in lower und upper bounds für die sieben Paramter. "Nebenbedingungen", das wäre quasi eine Auswahl einer Untermenge des 7-dimensionalen Raums? Nein, solche Nebenbedingungen gibt es nicht.
* Was meinst Du mit iterativem Output? In meinem letzten Beitrag habe ich Zeilen abgedruckt, die die Zielfunktion bei jedem Aufruf ausgibt. Diese kommen bei einem erneuten Aufruf anscheinend exakt genauso wieder raus... (ich habe nur die letzten Zeilen verglichen, das sieht reproduzibel aus), auch derAbbruch erfolgt nach der gleichen Zahl von Aufrufen.

Herzlichen Dank noch mal, dass Du Dich dieser Frage annimmst... wäre toll, wenn es "nur" ein Bedienfehler ist, oder sich über die Parameter von fmincon evtl. etwas verbessern lässt.

Kleine Anmerkung zu loglike: da ich zuerst nicht mit fmincon, sondern mit fminsearch gearbeitet hatte, beschränkt loglike die Parameter noch einmal, wenn sie denn außerhalb der bounds fallen sollten. Bei Aufrufen von fmincon sollte das ja aber ohnehin nicht passieren.

Beste Grüße aus Kiel
Chris

debug.zip
 Beschreibung:

Download
 Dateiname:  debug.zip
 Dateigröße:  10.15 KB
 Heruntergeladen:  16 mal
Private Nachricht senden Benutzer-Profile anzeigen
 
Chris_Kiel
Themenstarter

Forum-Newbie

Forum-Newbie


Beiträge: 8
Anmeldedatum: 05.01.21
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 06.01.2021, 18:03     Titel:
  Antworten mit Zitat      
PS: Ich habe dann fmincon durch fminsearch ersetzt. Da findet er angeblich kein lokales Minimum, läuft länger, bis die maximale Iterationszahl erreicht ist, und ist dann aber deutlich besser als fmincon: 1937. Ich mache inzwischen Folgendes: loglike führt selbst Buch, welches Ergebnis es retourniert, und ob dieses evtl. besser (kleiner) ist als das Kleinste bisher, dann merkt es sich die Parameter in einer global Variable. So kann ich dann am Ende auf die Parameter zurückgreifen, die zum kleinsten Wert geführt haben... sie sind identisch (Differenz echt Null) zu dem, was fminsearch als Parametersatz zurückgibt (auch wenn der letzte Aufruf vor dem Abbruch eine Kleinigkeit schlechter war). Mit anderen Worten: fminsearch liefert diejenigen Parameter, die den absolut kleinsten Funktionswert erzielt haben.

Warum fminsearch besser funktioniert als fmincon (mir dann allerdings aufzwingt, dass ich in der Zielfunktion die Parameter selbst beschneide), verstehe ich nicht...
Private Nachricht senden Benutzer-Profile anzeigen
 
Chris_Kiel
Themenstarter

Forum-Newbie

Forum-Newbie


Beiträge: 8
Anmeldedatum: 05.01.21
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 06.01.2021, 18:49     Titel:
  Antworten mit Zitat      
wobei so richtig gut ist auch fminsearch nicht. Es findet
Code:

    [0.0220   61.9500    1.5125    0.6229    0.0438    0.4945    0.5172]
 


Dabei kam ein LL-Wert von 1937,127 heraus.

Ich habe dann eine kleine Routine geschrieben, die mir erlaubt, von Hand mal diesen, mal jenen Parameter zu verändern, und ich fand folgende bessere Parameter

Code:

[.001 61.97 1.5125 .63 .00 .5 .5]
 


die einen LL-Wert von 1899,696 ergeben. Auch optisch überzeugt die Modellanpassung wesentlich mehr.

Anmerkung: wenn der drittletzte Parameter auf 0 steht, sind die letzten beiden unwirksam. Der erste Parameter könnte quasi Null sein... erst ab einer gewissen Größe (so um die 0.15) verändert er etwas. Der von fmincon gefundene Wert lag da noch drunter... im Bereich 0 - 0.15 spielt er keine Rolle.

Hmm, noch keine gute Lösung gefunden...
Private Nachricht senden Benutzer-Profile anzeigen
 
Harald
Forum-Meister

Forum-Meister


Beiträge: 22.729
Anmeldedatum: 26.03.09
Wohnort: Nähe München
Version: ab 2017b
     Beitrag Verfasst am: 07.01.2021, 10:59     Titel:
  Antworten mit Zitat      
Hallo,

durch die Schachtelung von Funktionen, Verwendung von globalen Variablen, und fehlende Kommentierung ist das ganze für mich schwer nachvollziehbar.

Zitat:
Sagen wir so: ich wüsste keinen Grund, warum sie nicht glatt sein sollte.

Sollten beispielsweise in addtodata je unterschiedliche Zweige genommen werden, ist die Funktion an diesen Stellen nicht nur nicht differenzierbar, sondern vermutlich sogar unstetig. Da diese Funktion allein durch loglike(x0) 55000 Mal aufgerufen wird, gibt es sehr viele solcher potenziellen Unstetigkeiten.
Falls die Funktion nicht annähernd glatt ist, ist es nicht sinnvoll, fmincon zu verwenden, da es gradientenbasiert arbeitet. Das erklärt, dass du mit fminsearch bessere Ergebnisse bekommst, da fminsearch nicht gradientenbasiert arbeitet.

Zitat:
Anmerkung: wenn der drittletzte Parameter auf 0 steht, sind die letzten beiden unwirksam.

Auch das spricht gegen Glattheit.

Zitat:
Was meinst Du mit iterativem Output?

Code:
opts = optimoptions(@fmincon, 'Display', 'iter');


Ich habe mal patternsearch aus der Global Optimization Toolbox versucht und komme da mit
Code:
x = patternsearch(@loglike,x0,[],[],[],[],lb,ub);

auf
585 (269.32 s): LL = 1900.746 +- 2.856, P = 0.0200 61.8789 1.4375 0.6449 0.0116 0.0000 0.5000

Das hat sich allerdings schon nach ca. 300 Funktionsaufrufen ziemlich "festgelaufen", dürfte also ein anderes lokales Minimum sein als das von dir gefundene.

Deine Lösung [.001 61.97 1.5125 .63 .00 .5 .5] verletzt für die erste Komponente die untere Schranke.

Wenn ich die untere Schranke für die erste Komponente auf 0 setze und deine Lösung als Startwert verwende, findet patternsearch die Lösung
446 (196.65 s): LL = 1899.034 +- 3.242, P = 0.2576 61.9700 1.5125 0.6154 0.0000 0.5000 0.0000

Grüße,
Harald
_________________

1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Private Nachricht senden Benutzer-Profile anzeigen
 
Harald
Forum-Meister

Forum-Meister


Beiträge: 22.729
Anmeldedatum: 26.03.09
Wohnort: Nähe München
Version: ab 2017b
     Beitrag Verfasst am: 07.01.2021, 12:17     Titel:
  Antworten mit Zitat      
Hallo,

Nachtrag:

ich kam noch auf den Gedanken, auch surrogateopt aus der Global Optimzation Toolbox zu versuchen. Das kommt ohne Startwert aus und lieferte in einem Versuch:
0.0160 62.1566 1.4626 0.6416 0.0001 0.4207 0.4175
mit LL = 1896.6

Wenn du gute Anfangswerte angeben kannst, ist das natürlich um so besser.
Nachteil dieses Ansatzes ist, dass er stochastisch ist, also nicht immer die gleichen Ergebnisse liefert.

Grüße,
Harald
_________________

1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Private Nachricht senden Benutzer-Profile anzeigen
 
Chris_Kiel
Themenstarter

Forum-Newbie

Forum-Newbie


Beiträge: 8
Anmeldedatum: 05.01.21
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 08.01.2021, 11:20     Titel:
  Antworten mit Zitat      
Hallo Harald,

besten Dank für Deine Beratung. Ich habe dann festgestellt, dass unsere Uni eine Campuslizenz hat (seit neuestem), und da ist auch die Global Optimization Toolbox drin. Diese Lizenz habe ich heute Vormittag installiert, und nun läuft gerade pattern search, und es sieht gut aus Smile

Ich werde es nachher noch mit surrogateopt vergleichen. Auf jeden Fall scheint mein Problem nicht für fminsearch oder auch fmincon geeignet. Trotzdem komisch, dass fmincon ignoriert, dass es schon mal bessere Werte gesehen hatte... egal. Ich will nicht fmincon verstehen, sondern mein Problem lösen, und mit der global optimization toolbox werde ich das schaffen Smile

Herzlichen Dank
und beste Grüße aus Kiel
Chris
Private Nachricht senden Benutzer-Profile anzeigen
 
Chris_Kiel
Themenstarter

Forum-Newbie

Forum-Newbie


Beiträge: 8
Anmeldedatum: 05.01.21
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 08.01.2021, 13:16     Titel:
  Antworten mit Zitat      
surrogateopt funktioniert noch besser Smile Ok, es ist stochastisch, es liefert Werte zwischen 1901 und 1895... aber alle diese Lösungen sind viel besser, als was fmincon geliefert hätte.

Ob es Sinn machen könnte, erst surrogateopt, und dann ausgehend von dessen Lösung noch mal fminsearch laufen zu lassen? Ich habe das jetzt ein paar Mal probiert... immerhin hat surrogateopt einmal (weil es ja stochastisch ist) eine eher schlechte Lösung (1917) gefunden, und fminsearch hat die dann doch noch mal deutlich verbessert.

Beste Grüße
Chris
Private Nachricht senden Benutzer-Profile anzeigen
 
Harald
Forum-Meister

Forum-Meister


Beiträge: 22.729
Anmeldedatum: 26.03.09
Wohnort: Nähe München
Version: ab 2017b
     Beitrag Verfasst am: 08.01.2021, 13:28     Titel:
  Antworten mit Zitat      
Hallo,

Zitat:
Trotzdem komisch, dass fmincon ignoriert, dass es schon mal bessere Werte gesehen hatte...

Die besseren Werte wurden nur gesehen, als es darum ging, den Gradienten zu schätzen. Wenn die Funktion glatt ist, ist die resultierende nächste Iteration in der Regel besser als die dazwischen liegenden Funktionsauswertungen.

Gut, dass du die Global Optimization Toolbox zur Verfügung hast. Dann sind vielleicht auch die Vorschläge zur Wahl des Solvers interessant:
https://www.mathworks.com/help/gads.....her-solver.html#bu9r6hl-6

Ich denke auch, dass du mit etwas Experimentieren eine zufriedenstellende Lösung für dein Problem finden wirst. Was mich verwundert ist, dass aus meiner Sicht weit auseinander liegende Parametersätze ähnliche Lösungen liefern. Es fällt mir allerdings schwer, daraus sinnvolle Schlüsse zu ziehen.

Meine Vermutung ist, dass du die Vorgehensweise dann auch auf andere Datensätze anwenden willst? Da wird die Frage sein, ob der Löser bzw. die Kombination von Lösern, die für den jetzigen Datensatz gut waren, auch dort gut sein wird. Das kommt wohl auf den Versuch an.

Da patternsearch tendenziell besser funktioniert als fminsearch, würde ich eher das patternsearch mit surrogateopt kombinieren als fminsearch. Man kann sich auch überlegen bzw. damit experimentieren, ob es sinnvoller ist, erst surrogateopt und dann patternsearch zu verwenden oder umgekehrt.

Grüße,
Harald
_________________

1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Private Nachricht senden Benutzer-Profile anzeigen
 
Chris_Kiel
Themenstarter

Forum-Newbie

Forum-Newbie


Beiträge: 8
Anmeldedatum: 05.01.21
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 08.01.2021, 13:56     Titel:
  Antworten mit Zitat      
Hallo Harald,

Danke noch mal für Deine weitergehenden Tipps. Die Web-Seite empfiehlt ja auch patternsearch und dann surrogateopt... da ich in der Tat viele Datensätze untersuchen werde (150), und die sich teilweise sehr unterscheiden, kann ich surrogateopt gut gebrauchen, weil es keine Startwerte braucht. Und dann vielleicht in der Tat patternsearch hinterher... ich glaube, fmincon und fminsearch scheitern daran, dass meine Zielfunktion nicht differenzierbar ist (Knicke aufweist).

Weit auseinanderliegende Datensätze liefern gleiche Werte der Zielfunktion, weil manche Parameter andere "ausschalten": wenn der drittletzte auf Null steht, ist der zweitletzte egal, und wenn der erste klein ist (unter 0.15 oder so), ist der letzte egal. Und beim ersten scheint alles zwischen 0 und 0.15 aufs Gleiche hinauszulaufen.

Da ich für meine 150 verschiedenen Datensätze erst mal keine Vermutung für gute Startwerte habe, werde ich wohl zuerst surrogateopt verwenden und dessen Werte dann in patternsearch eingeben. Klingt jedenfalls jetzt nach der Kombi der Wahl...

Vielen Dank noch mal, und beste Grüße
Chris
Private Nachricht senden Benutzer-Profile anzeigen
 
Neues Thema eröffnen Neue Antwort erstellen



Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:

Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen
.


goMatlab ist ein Teil des goForen-Labels
goForen.de goMATLAB.de goLaTeX.de


 Impressum  | Nutzungsbedingungen  | Datenschutz  | Werbung/Mediadaten | Studentenversion | FAQ | goMatlab RSS Button RSS


Copyright © 2007 - 2021 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
Partner: LabVIEWforum.de

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.