STATA-FORUM.DE

[MariaS]

Ich stimme dir bei den 2 verschiedenen Datensätzen zu, wahrscheinlich ist es sorum besser.
Leider hab ich grad gemerkt, dass meine neue_bez Variable fehlerhaft ist. Denn obwohl Paaren die ID ihres Partners zugeordnet wird (also ein Wert vorhanden ist), gibt es doch viele Fälle, in denen der Partner gar nicht im Datensatz ist - obwohl er eine ID hat! Offenbar liegt das daran, dass ich meinen Arbeits-Datensatz aus 3 verschiedenen Datensätzen "zusammengemerged" habe und die entsprechenden Fälle nicht in allen 3 Ursprungsdatensätzen vorhanden waren und somit gelöscht wurden.

Ich muss also erst einmal meinen Datensatz so bereinigen, dass nur dann eine parid angegeben wird, wenn der Partner auch tatsächlich noch im Datensatz ist.
Unglücklicherweise weiß ich auch nicht, wie man das macht. Kannst du mir dabei helfen?

[daniel]

Ich muss also erst einmal meinen Datensatz so bereinigen, dass nur dann eine parid angegeben wird, wenn der Partner auch tatsächlich noch im Datensatz ist.
Unglücklicherweise weiß ich auch nicht, wie man das macht. Kannst du mir dabei helfen?

Möglich, dass ich helfen kann. Kannst Du näher beschreiben welche Struktur die Datensätze haben, die Du da -merge-st, und wie Du die (fehlerhafte) Variable erstellt hast?

[MariaS]

Also strukturtechnisch sind alle 3 Datensätze im long-format, sortiert nach pid und svyyear. Ein Pfad-Datensatz, in dem grundlegende Informationen enthalten sind z.B. sex, gebjahr, parid, partner (Art der Partnerschaft); ein Datensatz mit Variablen, die vom DIW selbst gebildet wurden und ein Datensatz, der die Variablen aus den Fragen des Fragebogens enthält z.B. Gesundheit, Bildung etc.

"Gemerget" hab ich die drei dann so:

Code: Alles auswählen

clear
use $path2\ppfadl_neu.dta
merge pid svyyear using $path2\pgen_neu.dta $path2\pl_neu.dta

drop if _merge != 3
drop _m*

Ok, zu beschreiben, wie ich die neue_Bez Variable gebildet habe, ist wiiiirklich schwierig, weil ich es eigentlich nur anhand der Daten erklären kann...

Schlussendlich musste ich die Variable neue-bez in 2 Schritten bilden.
Erst hab ich eine generelle Partnerschaftsvariable gebildet, da die bestehenden Partnerschaftsvariablen oft etwas widersprüchlich bzw. nicht eindeutig waren waren, was wohl daran liegt, dass ich mit einer Beta-Version arbeiten muss. Die von mir gebildete Variable hat folgende Ausprägungen :

* 0 kein Partner, geschieden, verheiratet getrennt, verwitwet
* 1 fester Partner, aber nicht im Datensatz
* 2 fester Partner, der im Datensatz ist
* 3 Ehepartner, der im Datensatz ist

und wurde so gebildet:

Code: Alles auswählen

gen partnerschaft=99
replace partnerschaft=0 if p0572==2 | partner==0 & p0572<=-1 | partner==0 & p0572==. | partner==-1 & p0572<0 & pgfamstd==3
replace partnerschaft=1 if p0572==1 & parid==-2
replace partnerschaft=2 if parid!=-2 & partner==2 | parid!=-2 & p0572==1
replace partnerschaft=3 if parid!=-2 & partner==1 | partner>=3 & pgfamstd==1

Das Problem ist eigentlich, dass ich die Unterscheidung "im Datensatz/nicht im Datensatz" einzig und allein anhand dessen getroffen habe, ob eine parid vorliegt oder nicht. Leider habe ich aber nicht überprüft, ob die Person mit der parid auch im Datensatz ist
Dieser Fehler hat sich dann in die Bildung der neue_bez Variablen übertragen, die schlicht so gebildet wurde:

Code: Alles auswählen

gen neue_bez=0
bysort pid: replace neue_bez=1 if partnerschaft==1 & partnerschaft[_n-1]==0
bysort pid: replace neue_bez=2 if partnerschaft==2 & partnerschaft[_n-1]==0 | partnerschaft==3 & partnerschaft[_n-1]==0


Mein Problem ist jetzt also, dass ich irgendwie überprüfen muss, ob die Person, die bei ihrem Partner mit parid angegeben wurde, auch wirklich im Datensatz ist und wenn nicht, muss die parid halt ein Missing enthalten...

[daniel]

Bevor ich mich näher mit dem Problem befasse, hier einige schnelle Anmerkungen zu einigen allgemeineren Punkten.

Anhand Deiner -merge- Syntax schließe ich, dass Du Stata 10 oder füher verwendest. Falls nicht, solltest Du die neue -merge- Syntax verwenden, die weniger fehleranfällig ist.

Zeilen wie

Code: Alles auswählen

replace partnerschaft=0 if p0572==2 | partner==0 & p0572<=-1 | partner==0 & p0572==. | partner==-1 & p0572<0 & pgfamstd==3


funktionieren mit hoher Wahrscheinlichkeit nicht so, wie Du willst. Du solltest auf jeden Fall Klammern verwenden, auch wenn sie (zufällig!) nicht nötig sein sollten. Hast Du bei dieser Zeile bsp. bedacht, dass & Operatoren vor | Operatoren evaluiert werden?

Die Verwendung von subscripten, wie in

Code: Alles auswählen

bysort pid: replace neue_bez=1 if partnerschaft==1 & partnerschaft[_n-1]==0


bei Paneldaten im long-format zu verwenden ist riskant, weil Lücken in den Jahren Probleme verursachen können. Besser ist es hier meist mit time series Operatoren zu arbeiten. In diesem Beispiel stellt Du nicht sicher, dass partnerschaft[_n-1] auch tatsächlich zeitlich vor (nicht nur in der aktuellen Sortierung des Datensatzes) partnerschaft[_n] liegt. Die Sortierung nach pid ordnet alle anderen Variablen zufällig an. Wenn Du Glück hast, sind die Jahre, auf die Du mit [_n - 1] sicher abzielst, in der korrekten Reihenfolge. Verlassen würde ich mich darauf nicht.

[MariaS]

Die merge-Syntax habe ich einfach aus einem früheren Projekt mit Stata 10 übernommen - ich arbeite jetzt zwar mit Stata 12, kenne aber die neue Syntax nicht.

Dass & vor | bedacht wird, ist mir klar und so habe ich auch die Syntax erstellt. Persönlich würde ich zwar auch lieber Klammern verwenden (quasi als Sicherheitsnetzt), habe aber bei meiner damaligen Recherche nichts zu deren Verwendung bei replace gefunden.
Schlussendlich ist das aber nicht das Problem bei der Erstellung, sondern wie gesagt, die fehlenden Partner trotz angegebener Partner-Id.

Der gesamte Dtensatz ist nach pid & svyyear sortiert - von vornherein. Mit dem bysort wollte ich nur erreichen, dass der Befehl pro Person durchgeführt wird. Im Nachhinein hätte by wahrscheinlich gereicht, aber als ich eben zur Überprüfung

Code: Alles auswählen

bysort pid svyyear: replace neue_bez=1 if partnerschaft==1 & partnerschaft[_n-1]==0

eingegeben habe, kamen auch 0 real changes raus.

Das mit dem Panel-Datensatz oder das Verwenden von time series Operatoren ist wirklich nicht mein Problem. Ich habe diese ganzen(möglichen) Probleme und Lücken etc. entsprechend meinem präzisen Forschungsziel schon gehändelt - es geht mir ja nicht um eine Längschnitt- oder Panelanalyse. Ich verwende lediglich einen Paneldatensatz.

Meine Frage ist im Moment wirklich, wie kann ich die parid zu "-2" ändern, wenn der angegebene Partner doch nicht im Datensatz ist? Dann kann ich ja erst schauen, ob deine Vorschläge zu meiner ursprünglichen Frage funktionieren.

Danke an dieser Stelle erstmal für deine Geduld und Hilfe ^^

[daniel]

Ich wollte nicht zu weit abschweifen, sorry. Ich kann das nicht ganz lassen ...

Anstelle von

Code: Alles auswählen

bysort pid svyyear: replace neue_bez=1 if partnerschaft==1 & partnerschaft[_n-1]==0


willst Du hier

Code: Alles auswählen

bysort pid (svyyear) : replace neue_bez=1 if partnerschaft==1 & partnerschaft[_n-1]==0


schreiben (beachte die Klammer um svyyear). Weiteres dazu unter -help bysort-.

Klammern sind nicht vom Befehl (z.B. -replace-) abhängig, sondern Teil der expression, und werden so wie in der Mathematik üblich gesetzt und von Stata dementsprechend ausgewertet.

Zur neuen -merge- Syntax einfach -help merge- tippen.

Nun aber zurück zum Problem. Um zu checken, ob die parid auch unter den pid auftaucht, brauchst Du eigentlich nur eine Liste der parid. Die bekommst Du mit -levelsof-. Du brauchst dann lediglich die Fälle mit -2 zu ersetzen, deren pid nicht in der Liste der parid auftaucht. Hier ist ein code

Code: Alles auswählen

qui levelsof parid ,l(lvls) // gets a list of all parid and stores it in local macro lvls
token `lvls' // puts the first value of lvls in local macro 1, the second in 2, etc.

loc i 1
forv j = 1/`: word count `lvls'' {
   loc list`i' `list`i'', ``j''
   if !(mod(`j', 249)) loc ++i
}

g byte isin = 0
forv j = 1/`i' {
   qui replace isin = 1 if inlist(pid `list`j'')
}
qui replace parid = -2 if !(isin)
drop isin


Der mittlere Teil ist nötig, weil -inlst()- nur 255 Argumente erlaubt (laut Dokumentation -- ich bekomme bei 250 Probleme) und es weit mehr als 255 parid geben wird. daher müssen wir die Liste der Werte (in local lvls) in kleinere Teile "hacken".

Der code berücksichtigt noch keinerlei zeitliche Informationen. Ob das ein Problem darstellt, kann ich momentan nicht sagen.

[MariaS]

Vielen Dank für deine Antwort! Ich hoffe, das funktioniert...
Ich versuche es gleich morgen und berichte dann/frage weiter. Einen schönen Sonntagabend

[MariaS]

Leider klappt dein Vorschlag nicht, weil ich als Fehlermeldung "macro length exceeded" erhalte...
Außerdem hab ich noch nie mit Listen gearbeitet und wüsste, wenn es denn dann funktioniert nicht, wie ich

"Du brauchst dann lediglich die Fälle mit -2 zu ersetzen, deren pid nicht in der Liste der parid auftaucht."

umsetzen würde...

[daniel]

Die Umsetzung ist bereits im code implementiert. Das ist diese Stelle

Code: Alles auswählen

g byte isin = 0
forv j = 1/`i' {
   qui replace isin = 1 if inlist(pid `list`j'')
}
qui replace parid = -2 if !(isin)


Wann tritt denn der Fehler auf? Direkt bei -levelsof-?

[MariaS]

jap, der Fehler tritt gleich in der ersten Zeile auf.

Außerdem hab ich versucht, den neuen merge-Befehl zu verwenden, aber wenn ich versuche alle 3 Datensätze auf einmal zu mergen, in dem ich die master-Datei einlese und 2 using-Dateien angebe

Code: Alles auswählen

clear
use $path2\ppfadl_neu.dta
merge 1:1 pid svyyear using $path2\pgen_neu.dta $path2\pl_neu.dta

drop if _merge != 3
drop _m*


bekomme ich nach dem merge-Befehl "invalid 'C'" angezeigt. Darum hab ich jetzt in 2 Schritten "gemerged".

Code: Alles auswählen

clear
use $path2\ppfadl_neu.dta
merge 1:1 pid svyyear using $path2\pgen_neu.dta

drop if _merge != 3
drop _m*


merge 1:1 pid svyyear using $path2\pl_neu.dta

drop if _merge != 3
drop _m*

save $path2\Datensatz_191112.dta, replace


Ist das auch ok?