Statalist


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

Re: st: strange global macros


From   Keith Dear <keith.dear@anu.edu.au>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: strange global macros
Date   Thu, 24 Apr 2008 07:43:33 +1000

Hi Gabi,
Macros are strings, neither float nor integer. Your macro $t contains "20080421" (without the quotes of course). You need to be careful about the datatype of the variable to which you assign a macro value, not the macro itself. If you make date_cohort a "long" it will hold numbers like 20080421 exactly.
HTH
kd

At 02:13 AM 24/04/2008, you wrote:

Got it, thank you.

Do you know if there is any way to get macros to recognize large
integers as such and respond by storing them as long instead of float?

For this particular project I just replaced date_cohort with a Stata
date formated as %d. It's even easier on the human eye than the
YYYYMMDD format and it sorts properly.

Gabi

On 4/23/08, Austin Nichols <austinnichols@gmail.com> wrote:
> . di 20080421
> 20080421
>
> . di float(20080421)
> 20080420
>
> See
> help data_types
> and note that if date_cohort were double or long you would face no
> precision problem.
>
>
>
>
> On Wed, Apr 23, 2008 at 11:09 AM, Gabi Huiber <ghuiber@gmail.com> wrote:
> > I am having some trouble getting global macros to represent numbers properly.
> >
> > Every week I receive some csv files that are named things like file_20080331.csv
> >
> > I use these files in a series of do-files that reference them as
> > file_${t}.csv, and all is well.
> >
> > However, when at the very end I produce a rolling summary report file
> > where I want to record the date in the same format, I am getting a
> > surprise result. I am doing this:
> >
> > [...]
> > local lastline=${cycles}+1
> > set obs `lastline'
> > replace date_cohort=${t} in `lastline'
> > [...]
> >
> > Yet the date_cohort observation corresponding to ${t}=20080331 is
> > 20080332; and the one that corresponds to ${t}=20080421 is 20080420.
> >
> > It's strange, because if ${t} were anything but 20080421, my do-files
> > would produce a "file not found" error when trying to look for that
> > day's csv file. So I am sure that ${t} stores the correct value. What
> > I am not sure of is why it is rendering it with a day off in either
> > direction.
> >
> > Can anybody help?
> >
> > Thank you,
> >
> > Gabi
> > *
> *
> * 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/
>
*
* 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/

Dr Keith B.G. Dear
Senior Fellow in Biostatistics
National Centre for Epidemiology and Population Health
Australian National University
Canberra, ACT 0200, Australia
Tel: 02 612 54865, Fax: 02 612 50740
http://nceph.anu.edu.au/Staff_Students/staff_pages/dear.php
CRICOS provider #00120C

http://canberragliding.org/

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