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

Re: st: funny behaviour of _N

From   Philip Ryan <[email protected]>
To   [email protected]
Subject   Re: st: funny behaviour of _N
Date   Thu, 28 Aug 2008 16:55:19 +0930


Funny perhaps, but logical to Stata.

In code fragment 2. below you are using the -in- qualifier. -help in- explicitly states that -in- is followed by a range and gives allowable syntax for that range.
_N is not allowable syntax. Essentially it is not a number; it is what Stata calls a system variable. But its content as a number can be exposed by evaluation "on the fly". Try:

replace a=b in `=_N'

In code fragment 1. below you have forced the evaluation of the *expression* _N by using the "=". The number represented by _N now resides in local macro num. When num is subsequently expanded it presents to -in- as a syntactically correct range.

Probably about now, or shortly thereafter, you should read the User's Guide and at least selected parts of the Data Management volume of the documentation. It will repay the effort.


At 03:53 PM 28/08/2008, you wrote:

Hello everyone,

Please compare the following 2 code snippets : -


local num=_N
replace a=b in `num'


replace a=b in _N

Surprisingly only the 1st one works ! Could some one tell me why ?

Thank you,
*   For searches and help try:
Philip Ryan
Discipline of Public Health

Director, Data Management & Analysis Centre

Associate Dean (IT)
Faculty of Health Sciences

postal address:
Discipline of Public Health
Mail Drop 511
University of Adelaide 5005
South Australia

Level 6, Room 6-18
Bice Building
Royal Adelaide Hospital
North Terrace

tel +61 8 8303 3570
fax +61 8 8223 4075
CRICOS Provider Number 00123M
This email message is intended only for the addressee(s)
and contains information that may be confidential and/or
copyright. If you are not the intended recipient please
notify the sender by reply email and immediately delete
this email. Use, disclosure or reproduction of this email
by anyone other than the intended recipient(s) is strictly
prohibited. No representation is made that this email or
any attachments are free of viruses. Virus scanning is
recommended and is the responsibility of the recipient.

*   For searches and help try:

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