Deutsches R-Forum

Gude!

Ich versuche mittels nlsLM, Daten an eine Funktion mit mehreren Parametern anzupassen.
Das läuft in einer Schleife, und die Daten werden aus einer Datenbank gelesen, in der auch die Ergebnisse gespeichert werden. Und da die nlsLM-Funktion in manchen Fällen abbricht, ist das mittels Try gekapselt, und das funktioniert auch. (Und mit nlsLM stabiler als mit nls.)
Jetzt versuche ich, die nlsLM-Funktion zu gewichten - Und bekomme Fehler. Und da dieser Fehler auch im modifizierten Beispiel aus der Doku auftritt, erkläre ich mein Problem daran.

Wie bereits erwähnt, findet man in der "wfct {minpack.lm} R Documentation - Weighting function that can be supplied to the weights argument of nlsLM or nls" folgenden Code:
Der Code funktioniert auch. (Ich hab' es mit 3.4.0 64 und 32 Bit und MRO 3.4.0 auf Windows 10 Enterprise probiert.)

Nun baue ich ein Try drumherum:
---schnipp--- ---schnapp---

Dann bekomme ich folgenden Fehler:
---schnipp--- ---schnapp---

Mit 'weights = wfct(1/rate))' und ohne Try geht es:
---schnipp--- ---schnapp---

Ohne 'weights = wfct(1/rate))' und mit Try geht es:
---schnipp---
try(result<-nlsLM(rate ~ Vm * conc/(K + conc), data = Treated, start = c(Vm = 200, K = 0.05)), silent=FALSE)
---schnapp---

Aber nicht beides zusammen. Tja,... Und jetzt sitz' ich vor meinem Bioldschirm und kuck' wie 'ne Kuh wenn's donnert... - Und bin für jede Hilfe dankbar.

Dank&Gruß
schubbiaschwilli

Kannst du nicht die weights direkt berechnen und übergeben - kommt aus selbe hinaus:

Gude!

Danke für deine Mühe und Antwort. Ich fürchte nur, das mich das nicht weiterbringt, da x$weights ja nur die bereits vorher als Parameter in die nlsLM-Funktion eingegebenen Werte bzw. Gewichte zurückliefert. Und es ist nicht die gleiche Rechnung und liefert auch unterschiedliche Ergebnisse, also:

x <- nlsLM(rate ~ Vm * conc/(K + conc), data = Treated, start = c(Vm = 200, K = 0.05), weights = wfct(1/rate))
y <- nlsLM(rate ~ Vm * conc/(K + conc), data = Treated, start = c(Vm = 200, K = 0.05))

Tatsächlich get es ja um die Koeffizienten, die R berechnet, und mit denen ich weiterarbeite, also:

coef(x)
coef(y)

Aber vielleicht mache ich mit dem Try was falsch. Ich hab' auch mal TryCatch ausprobiert (mit dem gleichen Ergebnis), und bin halt kein R-Entwickler, ich benutze R als reines Tool zum Rechnen. Wie bereits erwähnt, hängt dahinter eine Datenbank mit den Werten/Daten zum Fitten und unterschiedlichen Startparametern. Ich lasse nlsLM je nach Datensatz ein paar hundert mal laufen, da nlsLM nur ein lokales, vom Startwert abhängiges Minimum liefert; ich suche aber ein globales Minimum, und ich hoffe, dass ich durch dieses Netz von Startwerten das globale Minimum finde (das Kriterium ist hier der Wert 'residual sum-of-squares').
Ich suche jetzt aber nicht unbedingt eine tolle mathematische Lösung, es reicht mir, wenn ich den Code zum Laufen bekomme - Sei es durch einen Workaround oder vielleicht gibt es irgendwo irgendwelche Einstellungen, oderoderoder...

Dank&Gruß
Schubbiaschwilli

Sorry, hab mich wohl leider nicht verständlich ausgedrückt, ich meinte so hier: Warum das Problem auftaucht? - vermutlich ein "Scoping" Problem (also wie R Werte die zu einem Namen gehören findet. Tut es nämlich in dem Fall nicht, da die Funktion innerhalb von try aufgerufen wird und somit in einem anderen Enviroment...). Ich persönlich tue mir aber bisher relativ schwer damit Environments in R gescheit zu verstehen

Gude!

Ich hatte es schon gestern Abend ausprobiert und eingebaut, und es läuft - Zumindest technisch, am Wochenende werd' ich mal ein paar Ergebnisse nachrechnen (nur der Sicherheit halber - nein, ich leide nicht unter Verfolgungswahn) - Danke! Ich hatte mich jetzt auf die Doku mit dem "wfct(1/rate)" verlassen, aber es scheint wie immer, es sind nur Empfehlungen.

Dank&Gruß
schubbiaschwilli

Würde ich so nicht sagen.
Du verwendest die Funktion nicht standardgemäß (wrap in try()), für die es sicherlich nicht getestet wurde.
Aber ja, wenn ich mir den Quellcode anschauen, sieht die Funktion nicht so nice programmiert aus... Ist aber auch ein nicht-trivial Sache...