Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: st: RE: run through every values of a variable


From   Nick Cox <n.j.cox@durham.ac.uk>
To   "'statalist@hsphsun2.harvard.edu'" <statalist@hsphsun2.harvard.edu>
Subject   RE: st: RE: run through every values of a variable
Date   Thu, 3 May 2012 21:05:51 +0100

I was referring to 

capture confirm var "555"

in which the -confirm- part is illegal. 

-levelsof- does _not_ leave r(varlist) in its wake. Where did you get that idea? 

Nick 
n.j.cox@durham.ac.uk 


-----Original Message-----
From: owner-statalist@hsphsun2.harvard.edu [mailto:owner-statalist@hsphsun2.harvard.edu] On Behalf Of tashi lama
Sent: 03 May 2012 21:00
To: statalist@hsphsun2.harvard.edu
Subject: RE: st: RE: run through every values of a variable

count might just do the magic. Thank you. And yes, after second peek , I found whatever was in italic. I did realise that capture confirm wouldn't work in the following example since levelsof arranges the obs values as row and they aren't necessarily variables. 

levelsof broker_id, clean 

foreach item of local `r(varlist)' {

     if "`item'"=="555" {

         ..........

     }

}

 

might work...

Thanks again



----------------------------------------
> From: n.j.cox@durham.ac.uk
> To: statalist@hsphsun2.harvard.edu
> Date: Thu, 3 May 2012 20:25:19 +0100
> Subject: st: RE: run through every values of a variable
>
> Your -confirm- statement is illegal syntax, and putting -capture- in front will just eat the syntax error, so that is not the way to go.
>
> If you want to check whether any value is 555 then you can just go (e.g.)
>
> assert broker_id != 555
>
> count if broker_id == 555
>
> These are some of the ways are finding whether any value is 555. The first will be contradicted if any value is 555. The second will return a positive count in the same circumstance.
>
> Using a loop is _very_ inefficient here. Your loop is illegal because -forvalues- doesn't understand _N as such; you need to evaluate it as `=_N'.
>
> Your references are not getting any more precise! "stata resource and support page" does not remind me where I wrote that, as (let me put this in a David Hoaglin-like understatement) I have written various pieces on Stata here and there, including various FAQs.
>
> But no matter: whatever is a placefiller indicating some generic command. There is no official Stata command -whatever-. If you look closely at what was written, "whatever" should be in italic or indicated by <whatever>. If not, let me know where you found it and we will fix it.
>
> Nick
> n.j.cox@durham.ac.uk
>
> tashi lama
>
> I have a variable broker_id in my dataset as follows...
>
> broker_id
>
> 6429
> 131
> 244
>
> and I have to see if "555" matches any of the values in a broker_id. Now, I think I could use some technique like
>
> levelsof broker_id, clean
> capture confirm var "555"
>
> but I am wondering if there is a st. forward way to do this using forvalues loop like this
>
> 1. When I did forvalues i=1/_N {
>
> if broker_id[`i']=="555" {
>
> ........
>
> I get invalid syntax. I am not so sure... Could someone explain?
>
> 2. I see that Nick has given a way to do this in stata resource and support page
>
> sysuse auto
>
> foreach i in 0 1 {
> whatever if foreign == `i'
>
> }
>
> I tried to run this and got unrecognized command whatever in return. Is it because whatever is an obsolete command? Any idea....
>
>
> *
> * For searches and help try:
> * http://www.stata.com/help.cgi?search
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/ 		 	   		  
*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/

*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index