Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: Programmers providing key words for use by -search-/-findit-


From   Fred Wolfe <[email protected]>
To   [email protected], Statalist <[email protected]>
Subject   Re: st: Programmers providing key words for use by -search-/-findit-
Date   Tue, 14 Dec 2004 04:39:59 -0600

I am one of those those who has written about this to the list previously. I want to comment on Joseph's suggestion and on searches and help files more generally.

There is a need to be able to search and find ado files that extends to those posted on the BC archives (available via ssc install) and to those ado files that users have written for their own us. It is not infrequent for me not to the remember the name of a program I have written, or even to forget that I had written a program several years ago. So I am all in favor of a search utility.

Joseph suggests that putting key words in the command's help file might be the way to go. I would like to demur. Not all programs have help files. Nick Cox suggests that all programs should have help files, but this doesn't doesn't always occur, particularly when the program is not for public use. Some authors, in effect, write a brief help file in the *! area of the program, thereby making it accessible through the -which- command.

For example, -getqol- is a command for which I have no help file, but all of the information needed by me can be accessed though which.

. which getqol
c:\ado\personal\getqol.ado
*! getqol v1.2.0 fw 07nov04 merges in eurqol, eq5d5sf, sf6d
*! keywords qol utilities

As you can see, I placed keywords in the program. So in slight disagreement with Joseph I think it would be best to place the keywords in the program not the help file.

I think that 3 items should be searchable: The file name, a brief description, and key words.

In the programs that I write the description is in all of the lines that begin with *! Keywords are on a separate line the begins *! keywords

To search my ado files,in a program I obtain the list of ado files from the -dir-command, and build a dta file (adolist.dta) from this list (I am using windows xp). It has 3 variables: adoname, description, keywords. From there it is a simple matter to search this file. For example (snipped on right to make room in an email):

. ndbadolist age, nod

+---------------------------------------------------------------------
| name description
|---------------------------------------------------------------------
| agedecade.ado agedecade.ado v1.0.1 fw 9/12/04 creates age by d
| agedecadepure.ado agedecadepure.ado v1.0.0 fw 5/1/04 creates age b
| agegroup1.ado agegroup1.ado v1.0.1 fw 1/19/04 creates age grou
| agesqr.ado agesqr v 1.0.1 8dec2004 FW makes age squared var
| mkedearnings.ado mkedearning.ado v 1.0.0 fw calculates expected e
|---------------------------------------------------------------------
| onsetage.ado onsetage v 1.1.0 8dec04 FW calculates onset age
| wages.ado wages.ado fw 7/4/03 - calculates expected MEDIAN
+---------------------------------------------------------------------

If Statalisters agree that a search utility is a good idea, it would helpful for some standards to be set. As noted above, my suggestion is to put the information in a program file, with *! and *! keyword providing the description and keys, respectively.

It would be good top hear other ideas and perhaps an ad hoc standard could be developed. Or perhaps Stata Corp has some ideas about how to do this.

Michael Blasnick has also developed a program (which he kindly sent to me) that performs program searches. He might want to comment as well.

Fred Wolfe









At 11:11 PM 12/13/2004, Joseph Coveney wrote:

Would it be worthwhile for programmers to provide key words, perhaps in the
command's help file, to be detected by -search- or -findit-?  The key words
could be flagged perhaps in a dedicated smcl format in order
for -search-/-findit- to easily parse, for example, {kw:date}
{kw:conversion}.  Maybe it would speed the search if they were set-off in
their own paragraph in the help file, much as for the key words section of
manuscripts.

This was prompted yesterday when Svend Juul pointed out Nick Cox's -todate-
as a much more convenient alternative to a "first principles" approach that
I had suggested earlier.  This is certainly true, provided that you know
about its existence.  A few experimental tries with -findit- and -search-
(using terms such as "date" "conversion" "string" and so on, variously
singly or in combination) either pulled up hundreds of irrelevant hits or
missed it.

I recall that the problem of avoiding -search-/-findit- overlooking
user-written contributions has come up on the list before, but I don't
recall whether there has been any resolution other than for interested users
to notify StataCorp ad hoc of user-written contributions that seem to be
overlooked or difficult to catch.  If that's as it stands, then perhaps a
more systematic approach would be better.

Obviously, the concept of set-off or smcl-identified key words is no
panacea.  Its success will still depend upon both programmer and future user
formulating a problem in terms of the same key words, which doesn't always
happen for a variety of reasons.  But it seems that a systematized approach
would go a long way toward helping a user quickly determine whether there's
a user-written contribution already available and tailored to the problem at
hand.

Joseph Coveney




*
*   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/

Fred Wolfe
National Data Bank for Rheumatic Diseases
Wichita, Kansas
Tel (316) 263-2125     Fax (316) 263-0761
[email protected]


*
*   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–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index