[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

From |
"Sergiy Radyakin" <serjradyakin@gmail.com> |

To |
statalist@hsphsun2.harvard.edu |

Subject |
Re: st: Re: function el() fails |

Date |
Sun, 17 Aug 2008 18:11:37 -0400 |

Thank you Kit, I don't remember having a naming conflict like this for a long time, perhaps because all vars were always lowercase and all matrices were all-caps in my previous programs, but now that I convert files from SPSS varnames come as they were set up there - all caps, and naming conflicts showed up. Even after Scott's and yours explanations, I still think it is quite confusing and more support for this issue. E.g. see an example of the error message that I consider to be helpful in my answer to Scott. Alternatively, Stata could check if matrix p exists, and answer "you are using variable "price" in an expression where an argument of type "matrix" is expected. Matrix "p" is defined. Did you mean matrix(p)?" similarly like Google asks when I make typos in queries. There is no magic, no AI here. If variables and matrices share the same namespace, then list p should tell something like "ambiguous abbriviation", right? (Also for "ambiguous abbreviation", why not list a couple of examples to the user? e.g. if I ask tab q, and there are two variables quantity and quality, why not automatically call "des q*" ?) Anyways, I think error messages in Stata have made a giant leap forward from the generic "syntax error" messages with "something is wrong" explanation as they were in Stata 7, but at the same time there is nothing magical in making them clear for understanding and helpful in terms of "ok it doesn't work. what do I have to change to make it work?" Best regards, Sergiy Radyakin On 8/16/08, Kit Baum <baum@bc.edu> wrote: > < > > This program works fine. The problem is the evil notion that allows Stata to > consider variable abbreviations. I always have the setting > > set varabbrev off > > and with varabbrev off the program works fine. If you turn it on the program > fails with 'type mismatch' on the last statement. Clearly the parser, with > varabbrev on, is mistakenly looking around for variables whose names begin > with p. This does appear to be a bug, because Stata should be looking for a > MATRIX name as the first argument to the el() function. It should not > examine the namespace of variables, whether or not their names are > abbreviated. > > Kit Baum, Boston College Economics and DIW Berlin > http://ideas.repec.org/e/pba1.html > An Introduction to Modern Econometrics Using Stata: > http://www.stata-press.com/books/imeus.html > > > On Aug 16, 2008, at 02:33 , Sergiy wrote: > > > // ----- BEGIN ------- > > sysuse auto > > > > matrix p=1 > > matrix a=p > > > > matrix dir > > > > matrix list a > > di a[1,1] > > di el(a,1,1) > > > > matrix list p > > di p[1,1] > > di el(p,1,1) > > // ----- END ------- > > > > According to the help file for Stata 9: > > > > el(A,i,j) the i,j element of A (same as A[i,j]) > > > > Note that the program above works for matrix name "a" and not "p". > > This made it difficult to identify the problem. Because the problem is > > observed for some datasets and not for others. > > > > * > * For searches and help try: > * http://www.stata.com/help.cgi?search > * http://www.stata.com/support/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/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**References**:**st: Re: function el() fails***From:*Kit Baum <baum@bc.edu>

- Prev by Date:
**Re: st: Function el() fails** - Next by Date:
**st: Counting distinct (not unique) values** - Previous by thread:
**st: Re: function el() fails** - Next by thread:
**st: Multicollinearity and Orthogonalization** - Index(es):

© Copyright 1996–2019 StataCorp LLC | Terms of use | Privacy | Contact us | What's new | Site index |