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: Rather blue screen than this :(

From   daniel klein <>
To   "" <>
Subject   Re: st: Rather blue screen than this :(
Date   Tue, 28 May 2013 15:52:13 +0200


the demonstarted behavior might not be convenient for you, yet I do
not see why you would expect anything else here.

A view is just that -- a view of the dataset currently in memory. If
that dataset chanegs (e.g. the order of variables -- or as far as Mata
is concerend -- columns) the view changes.

If you want a matrix representing the data in a certain condition
(e.g. in a given order, a subset of the data etc.) at one specific
point in time (or your do-file, for that matter), you should create a
copy of that data using -st_data()-.

If you insist on a view (and there are good reasons to), rewrite your code as

sysuse auto
keep in 1/5

m : st_view(V = ., ., ///
(st_varindex("price"), ///
st_varindex("weight"), ///
st_varindex("length"), ///

m : min(V)


m : min(V)

To further explain and comment on your suggestions that

"[...] Stata should resolve to varname at creating the view (NOT to
index asnow) and tolerate variable order changes. Or let the user
decide atcreating the view whether to favor name or index."

Strictly speaking, Stata does neither care about variable names nor
about indices here -- Mata does. And Mata does not know about
(variable) names, so you should use indices as shown in my example.

The same argument applies to your suggestion that

"Stata should destroy the view and make it unassigned when any
variable of the view is dropped. [...]"

Again, Stata does not do anything to the view. Mata does, but you seem
not to fully grasp the concept of a view matrix. It is not a copy, but
only a view of the actual dataset (that is the reason why it need so
few memory). In fact a view "and the Stata dataset are the same"
(Gould, 2005). So "destroying" the view would mean to "destroy" the
original dataset -- and clearly nobody wants his complete dataset to
be "destroied" when dropping one variable.

I think the direction of my argument is clear for your third
suggestuion, so i will just skip that.

I cannot fully answer your question

"[...] why doesn't it [i.e. Mata] issue an error with the following?!

but it is documented that

"Assignment does not cause promotion. Coding

V[1,2] = 4059.125

might store 4059.125 in the first observation of the second variable
of the view.  Or, if that second variable is an int, what will be
stored is 4059, or if it is a byte, what will be stored is missing."

In my undestanding the last example (byte variables) also applies to
string variables.

My guess on the issue of no error message is (again) that a view is
not an object that exists inside Mata independently from the actual
dataset, but is the actual dataset. Specifying -st_view()- means
looking at that dataset through the "numeric variables lense".

If I got something wrong here, please feel free to correct me.


Gould, William (2005). Mata Matters: Using views onto the data. The
Stata Journal, 5(4), 567-573.

Just spent the whole long weekend searching for what's wrong in my
code. I love mata, but IMHO this shouldn't be happening:

*   For searches and help try:

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