# Re: st: using vector notation to simplify coding

 From Dan Waldo To statalist@hsphsun2.harvard.edu Subject Re: st: using vector notation to simplify coding Date Fri, 14 Aug 2009 06:13:53 -0700 (PDT)

```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 <austinnichols@gmail.com> wrote:

> From: Austin Nichols <austinnichols@gmail.com>
> Subject: Re: st: using vector notation to simplify coding
> To: statalist@hsphsun2.harvard.edu
> 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
>
> On Wed, Aug 12, 2009 at 11:12 AM, Kit Baum<baum@bc.edu>
> 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/
```