Re: st: Avoiding use of Mata external variables in large programs

[Sergiy Radyakin <serjradyakin@gmail.com>]

Michael,

mata structures and better yet classes are nice and no reason to be
uncomfortable with. Given performance considerations, I think we can
rule out saving to an external settings file and consider the following
suggestion (see below).

You may experiment with the naming convention to find something that
appears acceptable, but note that nothing will survive 'clear all' unless
it is saved somewhere outside of the session, which usually means
traffic and problems with synchronization of multiple instances of Stata's
running your commands.

If you are willing to follow StataCorp's way, I suggest you look carefully at
the the following commands:
regress, which can replicate the last estimation output without specifying
the model again, and
graph, which can rebuild the last graph without retyping all specifications.

Regress saves the full estimation command in e()-results and these
settings are lost when the user runs another estimation command.

Graph creates a bunch of instances (objects) of misc Stata classes,
 which remain accessible until another command destroys them. You can
unwind them from inspecting .__GRAPHCMD and ._Gr_Global.

Hope this helps. See the Mata classes solution below, Sergiy

*******************first line of a do file
**************************************************
   mata
   mata clear

   // this is usually part of the lib or smth

   class SergiyRadyakinSettingsClass {
     public:
       real matrix num
   }

   // this is the first spell of mata code where you set your settings

   _SergiyRadyakinSettings=SergiyRadyakinSettingsClass()
   _SergiyRadyakinSettings.num=uniform(10,10)
   _SergiyRadyakinSettings.num

   mata des

   end


   // the user will do something here
   // hope is that she will not type 'mata mata clear'
   describe
   clear

   mata
    //this is the second spell of mata code;
_SergiyRadyakinSettings.num is still available here
     _SergiyRadyakinSettings.num


   end

******************* last line of a do file
**************************************************











On Wed, May 8, 2013 at 1:49 PM, Lacy,Michael <Michael.Lacy@colostate.edu> wrote:
> I'll respond here to the helpful comments of both Sergiy Radyakin and
> Christophe Kolodziejczyk, responding to my question  described in more detail
> at http://www.stata.com/statalist/archive/2013-05/msg00247.html
>
>
>>On Tue, May 7, 2013 at 1:41 PM, Lacy,Michael <Michael.Lacy@colostate.edu> wrote:
>
>>> I'm seeking advice about avoiding the use of Mata external variables in
>>> Mata/Stata adofile programs.  This use arises in passing intermediate
>>> results among different Mata functions ... My concerns have to do with
>>> keeping Mata variables and their names as limited in scope as possible,
>>> to avoid me or someone else accidentally clobbering them.
>>
>
> Sergiy Radyakin <serjradyakin@gmail.com> responded Tue, 7 May 2013 18:57:52 -0400
>>
>>I see similarity to the way svy commands are implemented in Stata:
>>
>>prog MyStataProg
>>    sysuse auto
>>   <some Stata commands>
>>   svyset[pw=weight]
>>   <some more Stata stuff>
>>    svy: mean price // which uses settings remembered in svyset
>>end
>>
>>SVY stores the settings among the dataset characteristics. Type -char
>>list- before and after svyset to see what it adds. These are the
>>_dta[_svy_*] settings. Note that the manufacturer (StataCorp) doesn't
>>give you any warning when there is a collision at svy. Apparently the
>>user should not use "_"-prefixed chars, the use of which is reserved
>>for programmers. This is a reasonable assumption and is safe "almost
>>always" :)
>
> Thanks, Sergiy. Knowing that StatCorp does similar things is "reassuring."
> To my view, using -tempname- is just the fancier version of this, since it
> amounts to picking an odd name that is guaranteed not to be in use.
> That would lead me toward the -tempname- strategy for making "protected" but
> public variables in Mata. I know there are occasions when referencing a local
> in a Mata program can be a problem, but I think it's ok here, per below.
>
>>
>>If this is not suitable, there are other alternatives, but then I need
>>more info, how much of those settings you need to save?
>
> In the particular case I'm working with, I'm most importantly going to be
> saving at most four matrices of dimension N X N, and I'd like to allow
> for N as large as a few thousand, plus some other few N X 1 matrices.
> For the NX N matrices, I'm doing something like:
>
> prog StataProg
> ... Stata commands to prepare data for Mata
> forval i = 1/4 {
>    tempname stub`i'
>    mata: ``stubi' = SomeMatrixReturnedBySomeFunction()
> }
> ...
> mata: DoSomething("`stub'", nvars)    // where DoSomething uses `stub1' ,..., `stub4'
> end
>
>
> (For efficiency of passing parameters, I think I will eventually want
>  `stub' to be a matrix of pointers to matrices rather than matrices,
> but I think that's another matter.
>
>
>>how much
>>performance matters? how much security matters? (are you protecting
>>data from accidental collisions? protecting something from the
>>user?etc)
>
> I'm concerned about the accidental collision, i.e., a user referencing
> or assigning to one of the public external variables.  I don't think (?) there
>  are security considerations, and yes, performance matters, since a large
>  Mata variable, like `stub1' = 1000 X 1000 matrix could well occur.
>
>
> Christophe Kolodziejczyk <ck.statalist@gmail.com> responded , 8 May 2013 15:46:44 +0200
>
>>I would use structures or classes to avoid external. Structures cannot
>>be used interactively though.
>
> I'd be interested to hear more about your thinking of how a structure would help here.
> To my view, it's still a publicly exposed variable name, though I suppose the complexity
> of the naming e.g., "MyStructure.A" as opposed to "A", would make someone less likely
> to accidentally assign a value to A or erroneously access a value from A
> Regarding classes, I'm deeply ignorant <grin>, so my initial reaction is that that seems
> like a complicated solution to an ordinary problem.  However, that likely reflects
> my lack of knowledge.
>
> Regards, and thanks,
>
> Mike Lacy
> Dept. of Sociology
> Colorado State University
> Fort Collins CO 80523-1784
>
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/faqs/resources/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/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/