Dan--
You should reshape the mes variable as well, which then is the measure
of calendar month. The j variable after reshape is inconsequential.
No merging required, and all subsequent data manipulation becomes easy
once you have long-format data.
On Fri, Aug 14, 2009 at 9:13 AM, Dan Waldo<[email protected]> wrote:
> Thanks for the suggestion, Austin. Reshaping is a good idea, although I am not sure how I'd implement that in my particular case: each record has 6 monthly figures (ing_1 through ing_6) but the months they're drawn from (mes_1 through mes_6) are not the same for all records.
>
> It's helpful to know that each record's months are sequential. So, one semi-hard-code method would be to create a small dataset containing a record for each possible value of mes_1 (in this case, July through October); the record would have mes_1 and def_1 though def_6, the latter being the appropriate months' deflators. Then this file is merged onto the base file:
>
> . clear
> . input mes_1 def_1-def_6
> 1. 7 1.07 1.06 1.05 1.04 1.03 1.02
> 2. 8 1.08 1.07 1.06 1.05 1.04 1.03
> 3. 9 1.09 1.08 1.07 1.06 1.05 1.04
> 4. 10 1.10 1.09 1.08 1.07 1.06 1.05
> 5. end
> . save def , replace
> . use ingresos , clear
> . merge mes_1 using def , sort uniqus
> . drop if _merge==2
> . gen ding_1=100*ing_1/def_1
> . gen ding_2=100*ing_2/def_2
> etc
> . drop def_1-def_6
>
> It's clunky but gets the job done. But it's not generalizable ... and the other solutions offered are.
>
> Dan
>
> --- On Wed, 8/12/09, Austin Nichols <[email protected]> wrote:
>
>> From: Austin Nichols <[email protected]>
>> Subject: Re: st: using vector notation to simplify coding
>> To: [email protected]
>> Date: Wednesday, August 12, 2009, 11:18 AM
>> Dan--
>> This is really more a data structure issue--you will save
>> yourself a
>> lot of trouble in the long run by reorganizing the data,
>> for example
>> by making it "long" format for panel regressions (help
>> reshape). If
>> you have month and year on the data, you can -merge- to get
>> a cpi
>> variable and deflate with a line like:
>> g realy=y/cpi
>> and see also -cpigen- on SSC.
>>
>> On Wed, Aug 12, 2009 at 11:12 AM, Kit Baum<[email protected]>
>> wrote:
>> > <>
>> > Dan said
>> >
>> > Thanks for the clarification, Kit. I am having trouble
>> shaking the SAS
>> > mindset on this stuff, and your note, along with
>> Michael's, have helped a
>> > lot. I "get" the mata approach, being a old Fortran
>> guy ...it feels like a
>> > cumbersome solution in Stata right now, but I am sure
>> that is a transitory
>> > feeling.
>> >
>> > Actually it is a very elegant solution, taking
>> advantage of the concept of
>> > 'view matrices' in Stata. Surely as another old
>> Fortran guy you remember the
>> > EQUIVALENCE statement. That's what is happening with a
>> view matrix (real
>> > programmers don't need no steenken pointers!) so that
>> changes in Mata to the
>> > contents of the matrix (Y in my code) actually changes
>> the contents of the
>> > Stata variables that populate the matrix. That is very
>> powerful (and
>> > naturally can be dangerous if misunderstood).
>> >
>> > See http://ideas.repec.org/p/boc/dsug09/06.html
>> > (and ITSP, which illustrates this at greater length)
>> >
>> > Cheers
>> > Kit
>> >
>> *
>> * For searches and help try:
>> * http://www.stata.com/help.cgi?search
>> * http://www.stata.com/support/statalist/faq
>> * http://www.ats.ucla.edu/stat/stata/
>>
>
>
>
>
>
> *
> * For searches and help try:
> * http://www.stata.com/help.cgi?search
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
>
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
