📄 m1_how.hlp
字号:
{smcl}
{* 31mar2005}{...}
{cmd:help m1 how}
{hline}
{* index source code}{...}
{* index object code}{...}
{* index istmt it}{...}
{* index .mlib library files}{...}
{* index .mo file}{...}
{* index libraries}{...}
{title:Title}
{p 4 4 2}
{bf:[M-1] how -- How Mata works}
{title:Description}
{p 4 4 2}
Below we take away some of the mystery and show you how Mata works. Everyone,
we suspect, will find this entertaining, and advanced users will find the
description useful for predicting what Mata will do when faced
with unusual situations.
{title:Remarks}
{p 4 4 2}
Remarks are presented under the headings
{bf:What happens when you define a program}
{bf:What happens when you work interactively}
{bf:What happens when you type a mata environment command}
{bf:Working with object code I: .mo files}
{bf:Working with object code II: .mlib libraries}
{bf:The Mata environment}
{title:What happens when you define a program}
{p 4 4 2}
Let's say you fire up Mata and type
: {cmd:function tryit()}
> {cmd:{c -(}}
> {cmd:real scalar i}
>
> {cmd:for (i=1; i<=10; i++) i}
> {cmd:{c )-}}
{p 4 4 2}
Mata compiles the program: it reads what you type and produces binary codes
that tell Mata exactly what it is to do when the time comes to execute the
program. In fact, given the above program, Mata produces the binary code
00b4 3608 4000 0000 0100 0000 2000 0000
0000 0000 ffff ffff 0300 0000 0000 0000
0100 7472 7969 7400 1700 0100 1f00 0700
0000 0800 0000 0200 0100 0800 2a00 0300
1e00 0300
{p 4 4 2}
which looks meaningless to you and me, but Mata knows exactly what to make of
it. The compiled version of the program is called object code, and it is the
object code, not the original source code, that Mata stores in memory.
In fact, the original source is discarded once the object code has been
stored.
{p 4 4 2}
It is this compilation step -- the conversion of text into object code --
that makes Mata able to execute programs so quickly.
{p 4 4 2}
Later, when the time comes to execute the program, Stata follows the
instructions it has previously recorded:
: {cmd:tryit()}
1
2
3
4
5
6
7
8
9
10
{title:What happens when you work interactively}
{p 4 4 2}
Let's say you type
: {bf:x = 3}
{p 4 4 2}
In the jargon of Mata, that is called an {it:istmt} -- an interactive
statement. Obviously, Mata stores 3 in {cmd:x}, but how?
{p 4 4 2}
What Mata does is first compile the single statement and store the
resulting object code under the name {cmd:<istmt>}. The result is
very much as if you had typed
: {cmd:function <istmt>()}
> {cmd:{c -(}}
> {cmd:x = 3}
> {cmd:{c )-}}
{p 4 4 2}
except, of course, you could not define a program named {cmd:<istmt>}
because the name is invalid. Mata has ways of getting around that.
{p 4 4 2}
At this point, Mata has discarded the source code {cmd:x=3} and has
stored the corresponding object code. Next, Mata executes
{cmd:<istmt>}. The result is very much as if you had typed
: {cmd:<istmt>()}
{p 4 4 2}
That done, there is only one thing left to do, which is to discard the
object code. The result is very much as if you typed
: {cmd:mata drop <istmt>()}
{p 4 4 2}
So there you have it: you type
: {cmd:x = 3}
{p 4 4 2}
and Mata executes
: {cmd:function <istmt>()}
> {cmd:{c -(}}
> {cmd:x = 3}
> {cmd:{c )-}}
: {cmd:<istmt>()}
: {cmd:mata drop <istmt>()}
{hline}
{it:Technical Note:}
{p 8 8 2}
The above story is not exactly true because, as told, variable {cmd:x}
would be local to function {cmd:<istmt>()} so, when {cmd:<istmt>()}
concluded execution, variable {cmd:x} would be discarded. To prevent
that from happening, Mata makes all variables defined by {cmd:<istmt>()}
global. Thus you can type
: {cmd:x = 3}
{p 8 8 2}
followed by
: {cmd:y = x + 2}
{p 8 8 2}
and all works out just as you expect: {cmd:y} is set to 5.
{p_end}
{hline}
{title:What happens when you type a mata environment command}
{p 4 4 2}
When you are at a colon prompt and type something that begins with
the word {cmd:mata}, such as
: {cmd:mata describe}
{p 4 4 2}
or
: {cmd:mata clear}
{p 4 4 2}
something completely different happens: Mata
freezes itself and
temporarily transfers control to a command interpreter not unlike
Stata's command interpreter. The command interpreter accesses Mata's
environment and reports on it or changes it. Once done, the interpreter
returns to Mata, which comes back to life, and issues a new colon
prompt:
: {cmd:_}
{p 4 4 2}
Once something is typed at the prompt, Mata will examine it to determine
if it begins with the word {cmd:mata} (in which case the interpretive
process repeats), or if it is the beginning of a function definition
(in which case the program will be compiled but not executed), or
anything else (in which case Mata will try to compile and execute it
as an {cmd:<istmt>()}).
{title:Working with object code I: .mo files}
{p 4 4 2}
Everything hinges on the object code that Mata produces, and, if you wish, you
can save the object code on disk. The advantage of doing this is that, at
some future date, your program can be executed without compilation, which
saves time. If you send the object code to others, they can use your program
without ever seeing the source code behind it.
{p 4 4 2}
After you type, say,
: {cmd:function tryit()}
> {cmd:{c -(}}
> {cmd:real scalar i}
>
> {cmd:for (i=1; i<=10; i++) i}
> {cmd:{c )-}}
{p 4 4 2}
Mata has created the object code and discarded the source. If you now type
: {cmd:mata mosave tryit()}
{p 4 4 2}
the Mata interpreter will create file tryit.mo in the current directory;
see {bf:{help mata_mosave:[M-3] mata mosave}}.
The new file will contain the object code.
{p 4 4 2}
At some future date, were you to type
: {cmd:tryit()}
{p 4 4 2}
without having first defined the program, Mata would look along the
adopath (see help {helpb adopath} and
{bf:[U] 17.5 Where does Stata look for ado-files?})
for a file named tryit.mo. Finding the file, Mata loads
it (so Mata now has the object code and executes it in the usual way).
{* index .mlib library files}{...}
{* index libraries}{...}
{title:Working with object code II: .mlib libraries}
{p 4 4 2}
Object code can be saved in .mlib libraries (files) instead of .mo files.
.mo files contain the object code for one program. .mlib files contain
the object code for a group of files.
{p 4 4 2}
The first step is to choose a name (we will choose lmylib -- library names
are required to start with the lowercase letter {it:l}) and
create an empty library of that name:
: {cmd:mlib create lmylib}
{p 4 4 2}
Once created, new functions can be added to the library:
: {cmd:mlib add lmylib tryit()}
{p 4 4 2}
New functions can be added at any time, either immediately after creation
or later, even much later;
see {bf:{help mata_mlib:[M-3] mata mlib}}.
{p 4 4 2}
We mentioned that when Mata needs to execute a function that it does not find
in memory, Mata looks for a .mo file of the same name. Before Mata does that,
however, Mata thumbs through its libraries to see if it can find the function
there.
{title:The Mata environment}
{p 4 4 2}
Certain settings of Mata affect how it behaves. You can see those
settings by typing {cmd:mata query} at the Mata prompt:
: {cmd:mata query}
{txt}{hline}
Mata settings
{col 18}set matastrict{col 36}{res}off
{txt}{col 18}set matalnum{col 36}{res}off
{txt}{col 18}set mataoptimize{col 36}{res}on
{txt}{col 18}set matafavor{col 36}{res}space{txt}{col 49}may be {res:space} or {res:speed}
{col 18}set matacache{col 36}{res}400{txt}{col 49}kilobytes
{col 18}set matalibs{col 36}{res}lmatabase;lmataado{txt}
{col 18}set matamofirst{col 36}{res}off{txt}
: _
{p 4 4 2}
You can change these settings using {cmd:mata set};
see {bf:{help mata_set:[M-3] mata set}}.
We recommend the default settings, except that we admit to being partial
to {cmd:mata set matastrict on}.
{title:Also see}
{p 4 13 2}
Manual: {hi:[M-1] how}
{p 4 13 2}
Online: help for
{bf:{help mata:[M-0] intro}},
{bf:{help m1_intro:[M-1] intro}}
{p_end}
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -