Statalist The Stata Listserver


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: RE: RE: RE: numlist abbreviations not at all interpreted differently in egenmore's eqany S8


From   "Nick Cox" <n.j.cox@durham.ac.uk>
To   <statalist@hsphsun2.harvard.edu>
Subject   st: RE: RE: RE: numlist abbreviations not at all interpreted differently in egenmore's eqany S8
Date   Sun, 5 Mar 2006 23:06:34 -0000

The misleading title of this thread is being perpetuated. 

The -eqany()- function of -egen- has never been part 
of -egenmore-, as Jennifer did point out earlier in  a 
correction. I believe that someone posed a problem 
on Statalist which led to its first being written by myself
in about 1998. It was formally published as part of another package, 
called -egenodd-, in STB-50 and then revised in
STB-57, and then incorporated officially in Stata 7. 
In Stata 9, as part of a tidying-up of names by StataCorp provoked 
by Svend Juul's witty criticisms, it was renamed -anymatch()-. 

To repeat, Jennifer's question was whether there is a problem
with this -egen- function, and the short answer is No. 

Another way to see this is to note
that you can look directly at the code, as -egen- 
functions are all written in Stata. You need one little
detail, that -egen- function -foo()- will be defined by a
program in file _gfoo.ado. Thus, the prefix is always 
_g. 

Now in Stata 9 there is an especially easy way to 
do this: 

. viewsource _ganymatch.ado

finds the file and opens it up in the Viewer. There
is more on -viewsource- in Stata Tip 30 
"May the source be with you", which is in 
Stata Journal 6(1). 

In earlier versions of Stata, you just need 
to find the file (e.g. with -findfile- or 
-which-) and open it up with the Viewer
or an editor. 

Here is the function code. The key point is
that the -numlist- fed to -values()- is interpreted
as part of the -syntax- statement. Hence if there 
were a problem with different kinds of numlists, it
lies with -syntax-. As it happens, there is no such 
problem. 

*! version 1.0.0  04oct2004
program define _ganymatch
	version 6.0, missing
	gettoken type 0 : 0
	gettoken g 0 : 0
	gettoken eqs 0 : 0
	syntax varlist(min=1 numeric) [if] [in], /*
		*/ Values(numlist int) [BY(string)]
        if `"`by'"' != "" {
                _egennoby anymatch() `"`by'"'
        }

	tempvar touse 
	mark `touse' `if' `in' 
	tokenize `varlist' 
	local nvars : word count `varlist' 
	local nnum : word count `values'
	quietly {
		gen byte `g' = 0    /* ignore user-supplied `type' */
		forval i = 1 / `nvars' {
			forval j = 1 / `nnum' { 
				local nj : word `j' of `values' 
				replace `g' = 1 if ``i'' == `nj' & `touse'
			}	
		}
	}
	if length("`varlist'") >= 69 {
		note `g' : `varlist' == `values' 
		label var `g' "see notes"  
	}       
	else if length("`varlist' == `values'") > 80 {
		note `g' : `varlist' == `values'
		label var `g' "`varlist': see notes"
	}
	else {
		label var `g' "`varlist' == `values'"
	}
end

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

Marino, Jennifer
 
> Thanks very much for the explanation - I'm sorry for the delay in my
> thanks, but I was out of town.
> 
> I did consult -help numlist- and [U]14.1.8 before writing, I promise,
> but plain  failed to see that the interval was dictated by the number
> listed before the range for 'to' and ':'. Boneheaded, indeed 
> - I think I
> misread all the pertinent examples because I expected all but the
> explicit interval definition (e.g. 1[10]100) to be simple range
> delimiters.
> 
> Thank you again.

Scott Merryman
 
> > Aren't these supposed to be the same?
> > 
> 
> No.  For the ":" and "to" syntax, the preceding number specify the
> interval used in constructing the number list.
> 
> For example:
> 
> 10 15 to 25 == 10, 15, 20, 25
> 
> which is different than 
> 
> 10 15/25 == 10 15, 16, 17,..
> 
> -help numlist- has many more examples.

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2020 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index