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

RE: st: Year to start 1st April

From   "Nick Cox" <[email protected]>
To   <[email protected]>
Subject   RE: st: Year to start 1st April
Date   Mon, 8 Mar 2004 09:31:09 -0000

There is a standard trade-off here. It is discussed
at some length in Stata Journal 2(4):411--427 (2002)
with reference to issues like that here, in which there 
are direct solutions making use of Stata's built-in functions
and canned solutions making use of an -egen- function. 

Broadly speaking, 

*  Most problems in this area can be solved in a few 
lines with calls to Stata's built-in functions, although 
it can take some rummaging through the documentation 
and some experience to become fluent with this approach. 
It also helps to be fluent with -by:-, -_n- and -_N-, 
and Stata's handling of true and false. 

* An -egen- function, when available, also often offers 
the convenience of sensible labelling, attention to missing
values and handles for -if- and -in-. These too are applicable
directly, but some problems can get very messy with these
extra complications. 

* However, if you rely on there being a canned solution 
to each problem, you will often be sorely disappointed. 
There is inevitably some capriciousness in whether 
someone has decided that a problem is worth writing an 
-egen- function for. (Users cannot write their own built-ins.) 

I don't think portability is a major issue provided the 
functions concerned are identifiable through -search- 
or -findit-, although the need to explain where you got
something can easily be overlooked. 

[email protected] 

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Richard
> Williams
> Sent: 07 March 2004 21:43
> To: [email protected]
> Subject: Re: st: Year to start 1st April
> At 03:46 PM 3/7/2004 -0500, Nick Winter wrote:
> >At 11:20 PM 3/5/2004 -0500, Richard Williams wrote:
> >>Whoops.  I think the original solution I posted quickly gets off a 
> >>day.  I think it is fixable, but how about this instead:
> >>
> >>. gen finyear = year(datevisit)
> >>
> >>. replace finyear = finyear - 1 if month(datevisit) < 4
> >
> >Just a quick note to note, as it were, that this approach 
> can be done in 
> >one line:
> >
> >    . gen finyear = year(datevisit) - (month(datevisit)<4)
> >
> >(This works because the logical condition will evaluate to 0 
> or 1, as 
> >appropriate.
> >
> >--Nick Winter
> I had tried to do something like that but it wasn't working because I 
> didn't have the parentheses on the final part of the 
> expression right.  For 
> those determined to use as few lines as possible, here is yet another 
> spacesaver:
> . gen finyear = cond(month(datevisit) < 
> 4,  year(datevisit)-1,  year(datevisit))
> The -cond- option seems like a nice alternative to a 
> generate/replace combo 
> of commands.
> My favorite solution so far is the ncyear solution suggested 
> by Nick Cox - 
> not so much because it saves typing but because it saves you 
> a lot of time 
> figuring out what to type.  But, I suppose there is something 
> to be said 
> for avoiding the use of addons for relatively simple tasks, 
> e.g. if the 
> code will be run on different machines then portability is 
> easier if you 
> stick to built-in functions.
> *
> *   For searches and help try:
> *
> *
> *

*   For searches and help try:

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