Statalist The Stata Listserver


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

st: RE: Scalars versus temporary variables in MLE


From   "Nick Cox" <n.j.cox@durham.ac.uk>
To   <statalist@hsphsun2.harvard.edu>
Subject   st: RE: Scalars versus temporary variables in MLE
Date   Tue, 20 Jun 2006 22:48:41 +0100

Thanks for the very detailed report, which moves us
forward a lot. 

Here's my diagnosis. 

In this example ln eta stands not for a single parameter, 
but for a vector. Therefore it cannot fit into a scalar. 
A scalar can _only_ hold a single value. 

The advice to use scalars, not temporary variables, 
is only good if what is being handled is single-valued. 
The point is that holding the same value again and 
again in every observation is wasteful of storage 
(and poor style). It is very bad advice otherwise. 
Presumably what would happen if you map a variable
onto a scalar is that only the first observation
would be used. 

My key first statement in this thread was 

"A side-issue with your program is that you appear to 
be putting lots of constants into variables. Using
scalars is much better style and less wasteful
of storage."

If I misread your problem and you were _not_ doing that, 
then the advice does not apply to your program. 

A relatively trivial point in your second program
is that you wrap -scalar()- around every scalar 
except -m- on one line. With this dataset no 
difficulty arises, but that is a source of bugs. 

Kit himself has recently been caught by a bug
of the same kind. 

Nick 
n.j.cox@durham.ac.uk 

DEEPANKAR BASU
 
> This is in response to the posts by Nick and Kit regarding my 
> observations about the problems that I faced when using 
> "scalars" in place of "temporary variables" (of double data 
> type) for doing a maximum likelihood estimation using the -lf- method.
> 
> Nick and Kit both pointed out that scalars and variables of 
> the double data type (whether temporary or permanent) have 
> EXACTLY the same precision. Kit had provided a small program 
> to test this, and indeed that program showed that scalars and 
> temporary variables had the same precision. Here's the program:
> http://www.stata.com/statalist/archive/2006-06/msg00580.html
> 
> I am sure they are right about the precision of the scalars. 
> But I was still unable to understand why my program works 
> with variables of the double data type but does not converge 
> with sacalrs. So I did the following experiment: I replicated 
>  a simple program (for estimating a Weibull model) from the 
> book by Gould, Pitbaldo and Sribney (page 57) and then ran it twice. 
> 
> Once I used temporary variables of the double data type (as 
> is given in the original program in the book); and the second 
> time I used scalars instead of the temporary variables 
> leaving everything else unchanged. Result: I don't get 
> convergence when I use scalars!
> 
> So, the question remains: is there something about the method 
> -lf- which requires variables of the double data type or does 
> scalars and variables (of the double data type) have 
> different precision which could not be detected by Kit's 
> simple program? Or, am I making some mistake? 
> 
> 
> I provide both the programs (FIRST PROGRAM has temporary 
> variables; SECOND PROGRAM has scalars) and output from 
> running them below; probably someone can throw some light on 
> this perplexing issue.

...

> SECOND PROGRAM
> __________________________________________
> capture program drop myweibul1_lf
> program myweibul1_lf
> version 8.1
> 
> args lnf leta lgam
> quietly {
>    scalar p = exp(`lgam')
>    scalar M = ($ML_y1*exp(-`leta'))^(scalar(p))
>    scalar R = ln($ML_y1)-`leta'
>    replace `lnf' = -M + $ML_y2*(`lgam' - `leta' + 
> (scalar(p)-1)*scalar(R))
> }
> 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/



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