Statalist The Stata Listserver


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

Re: st: Mata function stata() within program


From   Ulrich Kohler <kohler@wz-berlin.de>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: Mata function stata() within program
Date   Wed, 22 Mar 2006 10:29:07 +0100

Thank you, Alan, that solved the problem. Also thanks for the detailed 
explanation.

Hopefully, I can show you why I need all that next week in Mannheim

Uli

Alan Riley wrote:
> Ulrich Kohler asked about calling Stata (including a local macro
>
> substitution) from Mata:
> > I have a Mata function which looks as follows:
> >
> > -------------------------------------lsq.mata--
> >
> > (...)
> >
> > // Mata Function to extract the substitution costs from subcost-matrix
> > void showhash(real rowvector R)
> > {
> > 	string scalar key1
> > 	st_local("key1",key1)
> > 	key1 = strofreal(R[1,2])
> > 	st_local("key1",key1)
> > 	stata("local hash1 = mod(`key1',197)")
> > }
> >
> > (...)
> >
> > ------------------------------------------------
> >
> > The function is part of the mata-libary lsq.mlib, which compiles without
> > problems. All other function in the library works well. However, if I run
> >
> > -showhash()- from within Mata I got the following error:
> > : R = 2,3,5,4
> > : showhash(R)
> >
> > invalid syntax
> >                  stata():  3598  Stata returned error
> >               showhash():     -  function returned error
> >                  <istmt>:     -  function returned error
> > r(3598);
> >
> > Further investigation showed that the error is connected to the -stata()-
> > function. However, After running -showhash()- I can intactively run the
> > same
> >
> > -stata()- function without any problems:
> > : stata("local hash1 = mod(`key1',197)")
> > : stata("display `hash1'")
> >
> > 3
>
> `key1' is being substituted at compile time.  That is, when
> Stata reads the lines
>
>     void showhash(real rowvector R)
>     {
>             string scalar key1
>             st_local("key1",key1)
>             key1 = strofreal(R[1,2])
>             st_local("key1",key1)
>             stata("local hash1 = mod(`key1',197)")
>     }
>
> just before they are compiled by Mata, macros are substituted.
> This, what is compiled is
>
>     void showhash(real rowvector R)
>     {
>             string scalar key1
>             st_local("key1",key1)
>             key1 = strofreal(R[1,2])
>             st_local("key1",key1)
>             stata("local hash1 = mod(,197)")
>     }
>
> And,
>
>      local hash1 = mod(,197)
>
> produces a syntax error when it is executed later.
>
> The reason it works interactively afterward is that by that point
> the local macro 'key1' has already been defined, and thus what
> Mata sees is
>
>             stata("local hash1 = mod(1.234,197)")
>
> (or rather, it sees whatever number was in R[1,2] and thus
> was stored in `key1').
>
> You can see the advantage of this macro substitution in
> adoupdate.ado.  Type -which adoupdate- and then look at the
> file in a text editor (being careful to not modify it of course).
> Look for CMDNAME and the local macros after it, then search lower
> in the file to see how they are used.  Their values get substituted,
> not at run-time, but just before the lines are compiled.
>
> Ulrich needs to protect `key1' from being substituted just
> before compilation by coding
>
>             stata("local hash1 = mod(\`key1',197)")
>
> The string that will be compiled into the code to be passed to
> stata() will then literally be
>
>    local hash1 = mod(`key1',197)
>
> which is what Ulrich wants.
>
>
> Alan
> (ariley@stata.com)
> *
> *   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/

-- 
kohler@wz-berlin.de
+49 (030) 25491-361
*
*   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–2020 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index