Re: st: Rather blue screen than this :(

[Sergiy Radyakin <serjradyakin@gmail.com>]

Dear Daniel, thank your response. I do want to use views, I do want
the view data to change when the underlying data changes. But I also
want it to disappear when the underlying data disappears.

How does your suggested code resolve the problem? It exhibits the same
problem: first reported minimum is 15, and the second (after aorder)
is 0. Internally Stata is doing the same thing as you show: for each
variable I provided as string - get the index, remember the index,
(and that is the 16 bytes structure Mr Gould refers in his article:
4+4*vars)

On the comments:

1. You seem to contrast Stata vs Mata a lot. It is just a
presentation-to-the-user thing. It is still one stata.exe file (at
least the Windows version).

2. When I say Stata should remember varnames I mean that structure (16
bytes =4+4*vars) must hold not varindices, but varnames and tolerate
reshaffling of vars.

3. What in the above made you think that I do not understand how the
views work? A view is a separate entity. And you can destroy a view
without affecting the data. So your conclusion, /quote/: destroying"
the view would mean to "destroy" the original dataset , /end quote/ is
wrong: Destroying the view means simply removing the instance of the
view object from memory, nullifying it, etc

sysuse auto
list
mata st_view(V=.,.,"mpg price")
mata V
mata mata drop V
list
mata V

Note that absolutely nothing happened to the data when I destroyed the
view? This is exactly what I expect to happen automatically when the
DATA is destroyed (e.g. when the variable 'price' is dropped).

To put it completely trivial for those not into Mata and who do not
see a problem in the issue. The real world analogy is the following:
when the bank closes your banking account, it is reasonable to expect
that your banking (debit) card associated with that account also stops
working. The card is your view into your account data, it does not
have any money on its own. You swipe a card associated with a closed
account, the terminal tells you "no-good, error" (followed by cutting
the card in half with scissors, at least if we believe the Hollywood
movies).
http://answers.yahoo.com/question/index?qid=20120225072747AAzjgqG

But surprise, currently Stata (or Mata, or the procedure with an
offset 0x00CAF3E2, or whatever) is elegantly substituting your
cancelled account with somebody else's account !!! and completes the
transaction!! And is doing it completely silently! I want that card,
that bank, sigh.

On the promotion thing: promotion applies to expanding variables'
storage types only. Period.The width of the storage type can be
changed but the type itself - not. Period. The string will never
become a number and a number will never become a string as a result of
a promotion. Now in your description you are using a newly invented
term 'lens' as in "numeric variables lens'. Is that along the lines of
Eric Lippert's:
http://blogs.msdn.com/b/ericlippert/archive/2010/04/05/turning-a-bug-into-a-feature.aspx

sysuse auto
keep in 1/5
aorder
st_view(V=., ., "headroom length")
mata V
drop length
mata V

Now Mata would of course not show you strings, but it would not assign
the numeric values to string elements either. So it will keep on
loosing the information you post into the cells and again without any
warning.
The fallacy is that a string variable should never be taken by the
st_view. Neither initially when the user supplies it, nor later when
the user reshuffles the variables.

Historically in Stata:
  sysuse auto, clear
  keep if foreign
  replace foreign=1
Gives me a warning that '0 real changes made'. It is just a precaution
against some possible error that might happen. Indeed if 0 changes are
made => do I need this statement at all? do I want to replace with
ones? etc. Perhaps it's an error. Or perhaps not an error.

In the described case with Mata there is an error for sure. Not
ambiguous. Hey, programmer, you are referencing the variable that is
no longer there; don't you want to look at your code one more time?

Cheers, Sergiy

PS: I love Mata, seriously, I want it to be better yet
PPS: Is it still necessary to quote electronic publications here with
full title, or just enough to post the link? I don't understand
whether the full name of the same paper by Gould that I quoted is a
correction of my link-quote?



On Tue, May 28, 2013 at 9:52 AM, daniel klein <klein.daniel.81@gmail.com> wrote:
> Sergiy,
>
> 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"), ///
> st_varindex("mpg")))
>
> m : min(V)
>
> aorder
>
> 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.
>
> Best
> Daniel
>
>
> 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:
> *   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/