Verschachtelte Funktion-Umgebung-Auswahl

Schreibe ich einige Funktionen für das erledigen wiederkehrende Aufgaben, aber ich versuche zu minimieren, wie oft ich die Daten laden. Im Grunde habe ich eine Funktion, die einige Informationen und macht eine Zeichnung. Dann habe ich eine zweite Funktion, wird die Schleife Durchlaufen, und die Ausgabe mehrerer plots zu einem .pdf. In beiden Funktionen habe ich folgende code-Zeile:

if(load.dat) load("myworkspace.RData")

wo load.dat ist eine logische und die Daten, die ich brauchen, ist gespeichert in myworkspace.RData. Wenn ich den Aufruf der wrapper-Funktion, die durchläuft und Ausgabe mehrerer plots will ich nicht zum laden des workspace in jeder Aufruf der inneren Funktion. Ich dachte, ich könnte einfach laden Sie den Arbeitsbereich einmal in der wrapper-Funktion, dann die innere Funktion kann auf die Daten zugreifen, aber ich bekam eine Fehlermeldung, sonst.

Also mein Verständnis war, wenn eine Funktion nicht finden kann, die variable in seine lokale Umgebung (erstellt, wenn die Funktion aufgerufen wird), die Funktion Aussehen wird, das übergeordnete Umfeld für die variable.

Bin ich davon ausgegangen das übergeordnete Umgebung, die innere Funktion nennen, wäre die äußere Funktion. Offensichtlich ist dies nicht wahr:

func1 <- function(...){
  print(var1)
}

func2 <- function(...){
  var1 <- "hello"
  func1(...)
}

> func2()
Error in print(var1) : object 'var1' not found

Nach der Lesung zahlreiche Fragen, die Sprache manual, und diese wirklich hilfreichen blog-Beitrag, ich kam mit der folgenden:

var1 <- "hello"
save(list="var1",file="test.RData")
rm(var1)

func3 <- function(...){
  attach("test.RData")
  func1(...)
  detach("file:test.RData")
}

> func3()
[1] "hello"

Gibt es einen besseren Weg, dies zu tun? Warum nicht func1 look für Undefinierte Variablen in der lokalen Umgebung erstellt von func2, wenn es war func2 aufgerufen func1?

Hinweis: ich wusste nicht, wie dieser name in Frage. Wenn jemand bessere Vorschläge, ich werde es ändern, und Bearbeiten Sie diese Zeile aus.

Lexikalisches scoping bedeutet, dass die Funktion Aussehen wird, für die undefinierten Symbole in Ihre übergeordnete Umgebung, die nicht unbedingt die aufrufende Umgebung. Überprüfen Sie auch dies: github.com/hadley/devtools/wiki/Environments
Danke für den link. Ich werde die Arbeit durch, die an diesem Nachmittag.
Wenn Ihre Daten ist in form von dataframes, Sie könnte verwenden Paket data.table, und übergeben Sie Ihre Tabellen als argument zu func1 innen func3. Dieses Paket arbeitet, von Referenz-und nicht unerwünschte Kopien Ihrer Daten.
Nicht ganz sicher, warum es ist nicht zu sehen var1, aber beachten Sie, dass print(parent.frame()$var1) funktioniert einwandfrei.
es ist beabsichtigt, dass func1 können nicht sehen, diese Umgebungen. Wenn Sie func1 <- function... in der Konsole, die Sie erstellen ein Objekt vom Typ closure, die hat eine Umgebung, Immobilie, gleich R_GlobalEnv. Dies ist, wo R-look für Symbole nicht aufgelöst, in der Beurteilung der func1's Körper. Die Bewertung - Umgebung erstellt, die während der Ausführung func2 oder func3 ist irrelevant WRT-symbol lookup. Eine Problemumgehung ist die Verwendung parent.frame()$var1, als Richie wies oben, aber es ist sehr hässlich.

InformationsquelleAutor dayne | 2013-08-20

  1. 8

    Veranschaulichen, lexical scoping, sollten Sie Folgendes beachten:

    Ersten mal erstellen Sie eine sandbox-Umgebung, nur um zu vermeiden, die ach-so-common R_GlobalEnv:

    sandbox <-new.env()

    Nun setzen wir die zwei Funktionen drin: f, die sieht für eine variable mit dem Namen x; und g definiert, die eine lokale x und fordert f:

    sandbox$f <- function()
{
    value <- if(exists("x")) x else "not found."
    cat("This is function f looking for symbol x:", value, "\n")
}

sandbox$g <- function()
{
    x <- 123
    cat("This is function g. ")
    f()
}

    Formsache: Eingabe-Funktion-Definitionen in der Konsole bewirkt, dass dann im umgebenden Umwelt festgelegt R_GlobalEnv, so dass wir manuell die Kraft Gehäuse von f und g entsprechend der Umgebung, wo Sie "hingehören":

    environment(sandbox$f) <- sandbox
environment(sandbox$g) <- sandbox

    Aufrufen g. Die lokale variable x=123 nicht gefunden f:

    > sandbox$g()
This is function g. This is function f looking for symbol x: not found.

    Nun erstellen wir eine x in die global Umgebung und rufen Sie g. Die Funktion f suchen x zuerst in der sandbox und dann in der übergeordneten sandbox -,, die passiert werden R_GlobalEnv:

    > x <- 456
> sandbox$g()
This is function g. This is function f looking for symbol x: 456

    Nur um zu überprüfen, dass f sieht für x zuerst in sein Gehege, wir können eine x dort und rufen g:

    > sandbox$x <- 789
> sandbox$g()
This is function g. This is function f looking for symbol x: 789

    Fazit: symbol lookup in R folgt die Kette des umschließenden Umgebungen nicht die Auswertung frames erstellt, die während der Ausführung der verschachtelten Funktionsaufrufe.

    EDIT: Nur das hinzufügen einer Verknüpfung zu diese sehr interessante Antwort von Martin Morgan auf das Thema im Zusammenhang mit der parent.frame() vs parent.env()

    Dies ist die beste Darstellung, die ich gesehen habe. Vielen, vielen Dank! Ich war nicht wirklich zu verstehen, den Unterschied in Umgebungen und frames.

    InformationsquelleAutor Ferdinand.kraft

  2. 2

    Könnten Sie Verschlüsse:

    f2 <- function(...){
   f1 <- function(...){
     print(var1)
   }
   var1 <- "hello"
   f1(...)
 }
 f2()
    Richtig, aber ich brauche, um der Lage sein, die innere Funktion als stand-alone-Funktion. Ich wollte Sie nicht haben, um neu zu definieren die innere Funktion jedes mal, wenn ich den Aufruf der äußeren Funktion (nicht zu erwähnen, eine doppelte Reihe von code).
    Dann die sauberste Einstellung meiner Meinung nach: legen Sie alle Ihre Daten in einer Liste (my_data), dann geben Sie als Parameter an Ihre Funktion. Innerhalb der Funktion können Sie verwenden Sie mit(my_data, { } ), um eine zusätzliche Eingabe.

    InformationsquelleAutor Karl Forner

Schreibe einen Kommentar