West Addison <[email protected]> reports that at the bottom page 155
in the Stata 7 User's Guide, he finds the following example,
. generate sdif = dif / sqrt(V["price","price"])
and yet, when he tries to execute it, he gets an error:
. generate sdif = dif / sqrt(V["price","price"])
matrix operators that return matrices not allowed in this context
r(509);
The manual has an error and what West needs to type is
. matrix spp = V["price","price"]
. generate sdif = dif / sqrt(spp[1,1])
Explanation
-----------
Stata's expression parser has two modes of operation, known "scalar mode"
and "matrix mode". The -generate- command allows scalar expressions and
the -matrix- command allows matrix expressions. Matrix expressions are a
proper subset of scalar expressions.
To a certain point, this makes sense. It would be senseless to type
. generate newvar = syminv(V)
matrix operators that return matrices not allowed in this context
r(509);
When you attempt to use a matrix operator that returns a matrix, you get the
r(509) error message. In this case, a matrix obviously cannot be stored
in a dataset variable.
How I wish I could stop right here. However, for computer-technical reasons,
a few matrix-operators-returning-scalar we also classified as belonging to
matrix expressions, which is to say, they are treated just the same as
matrix-operators-returning-matrices. These few require memory and execution
time to setup and that setup must be done prior to execution of the
expression, and had these few operators been classified the other way, that
cost would have been paid prior to the execution of all expressions. Matrix
subscripting via row-and-column names is one of those operators.
So ocassionally you type what looks like a perfectly reasonable expression,
such as
. generate sdif = dif / sqrt(V["price","price"])
and you get the error "matrix operators that return matrices not allowed in
this context"; r(509). All you can do is grind your teeth and give in.
Take the part of the expression that Stata is complaining about, store
that in a 1x1 matrix, and then use that 1x1 matrix in your scalar expression.
-- Bill
[email protected]
P.S. The programmers among us will be dissatisified with my explanation.
"Surely," they will say to themselves, "there must have been a way to
avoid paying this fixed cost before the execution of *ALL* expressions.
Why not remember whether the setup needs to be done, whihc you can
determine during the parsing set, and then only perform the setup when
necessary?"
Exactly right. To explain why not, I have to delve into history.
Part of the cost is time and part of the cost is memory. It was
the memory that was the problem. In earlier days of Stata, memory
was always in short supply, and the scalar-expression executor is
called willy-nilly inside the Stata code, and sometimes when lots of
memory has already been allocated to other things. The problem was
that, even if one only did the setup when necessary, on some
computers (old Macintoshes come to mind) the memory simply would not
be available. Thus, a rule was passed against this for all
platforms.
The above is no longer a concern and so you are right, we could go
back and improve the code.
<end>
*
* 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/
