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

st: cut - we are all happy - updating and labelling aspect


From   "Jens M. Lauritsen" <[email protected]>
To   [email protected]
Subject   st: cut - we are all happy - updating and labelling aspect
Date   Fri, 09 Aug 2002 10:46:24 +0200

Possibly I should have waited a day with my comment yesterday since I get
the mails one day delayed (I read the digest form of statalist) and in the
meantime everything was settled with prompt and proper reactions from Stata
and others. 

I wish to clarify one aspect of automatic updating and behaviour of cut. I
wrote yesterday:

> Disregard automatic updates for crucial parts until you are dissatisfied
with the old
> one. Better having an old and somewhat simpler version than a new one
with uncertainty.

and Nick [email protected] answered :

>is rather puzzling to me. One can easily disregard official updates just
by not issuing -update-: but the trade-off between ...."

What I actually meant was that people should be careful about updating
programs in general. Several persons here had problems when updating from
paradox v3 to v4 or shifting from english to danish version etc. IN Stata I
see no reason to get v7 if v6 or v5 is fine for their purpose.

Regarding updating current Stata (v7) I suggest using "update query" every
so often and do it myself before major new rounds of analysis. 

The other general aspect of the discussion is when people want to make
Stata options a little different than the "official behaviour". This is
where the flexibility of Stata shows its large possibilities. E.g.:

A.
A user wishes 3 decimals in certain output instead of 1, just change the
format of that display line from %8.1f to %11.3f and you have a new output.
In this situation I would:
1. add a line at the top of the ado: *! Modified in line xx for display of
more decimals
2, change the name of the command, e.g. _cut to _cutjl and save the ado
under a new name to make sure I had not by mistake introduced an error in a
core or addon program. 

B.
An example of that is the cut command, where current behaviour could be
labelling left ends, wheras I prefer both ends, so I created a modified cut
- cutjl with a new option "interval":

use auto 
egen pgrp =cutjl(price), group(3) interval
* Summ price shows min 3291 and maxi 15906. and labels will be set to:
   
     Price |      Freq.     Percent        Cum.
------------+-----------------------------------
  3291-4481 |         24       32.43       32.43
  4482-5885 |         25       33.78       66.22
 5886-15906 |         25       33.78      100.00
------------+-----------------------------------
      Total |         74      100.00

Also sometimes I wish to have short labels: (suppose variable year has
values from 1901-1997):

egen ygrp = cutjl(year), group(4) interval xtract(2)
to produce the labels: 1901-34,1935-59,1960-85,1986-97

This is the core flexibility of Stata where we as users can add aspects and
behaviour as we prefer. Sometimes simple 1 minute aspects like the display
format for an output. And sometimes several days or weeks/months of work
when people write analysis specific ado's for a particular task. But always
saved under new names. 

To find the version of a given program we write: which egen        
but for egen functions one has to write: which _gcut           (not which cut)
This could be added to the hlp file for egen (and which). 



venlig hilsen

Jens M.Lauritsen, Lic.med. Overl�ge
Odense Universitetshospital
Ulykkes Analyse Gruppen, v. afd O
Sdr. Boulevard 29
DK5000 Odense C
Tlf: +45 6541 2293 Mobil +45 2173 2293
fax: +45 6613 6581 
Mail: 
Arbejde: [email protected]
Personlig: [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