Stata The Stata listserver

Re: st: Matrix subscripts using row and column names

From (William Gould, Stata)
Subject   Re: st: Matrix subscripts using row and column names
Date   Thu, 17 Jul 2003 08:32:50 -0500

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

        matrix operators that return matrices not allowed in this context

The manual has an error and what West needs to type is

        . matrix spp = V["price","price"]

        . generate sdif = dif / sqrt(spp[1,1])


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

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 


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

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

      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 

      The above is no longer a concern and so you are right, we could go 
      back and improve the code.

*   For searches and help try:
