Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From   "Lacy,Michael" <>
To   "''" <>
Subject   Re: st: Avoiding use of Mata external variables in large programs
Date   Wed, 8 May 2013 17:49:11 +0000

I'll respond here to the helpful comments of both Sergiy Radyakin and
Christophe Kolodziejczyk, responding to my question  described in more detail 

>On Tue, May 7, 2013 at 1:41 PM, Lacy,Michael <> 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 <> 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
>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'

(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

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 <> 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:

© Copyright 1996–2017 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index