Notice: On March 31, it was **announced** that Statalist is moving from an email list to a **forum**. The old list will shut down at the end of May, and its replacement, **statalist.org** is already up and running.

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

From |
Sergiy Radyakin <serjradyakin@gmail.com> |

To |
"statalist@hsphsun2.harvard.edu" <statalist@hsphsun2.harvard.edu> |

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

Date |
Wed, 8 May 2013 15:00:21 -0400 |

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/

**References**:**Re: st: Avoiding use of Mata external variables in large programs***From:*"Lacy,Michael" <Michael.Lacy@colostate.edu>

- Prev by Date:
**Re: st: Avoiding use of Mata external variables in large programs** - Next by Date:
**Re: st: inter-rater agreement for multiple raters and continuous variables** - Previous by thread:
**Re: st: Avoiding use of Mata external variables in large programs** - Next by thread:
**st: Avoiding use of Mata external variables in large programs** - Index(es):