Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From |
Nick Cox <n.j.cox@durham.ac.uk> |

To |
"'statalist@hsphsun2.harvard.edu'" <statalist@hsphsun2.harvard.edu> |

Subject |
st: RE: Convergence problems with Stata 12 |

Date |
Tue, 6 Sep 2011 13:36:17 +0100 |

I don't think this was ever answered, but there is an answer in -help whatsnew-. See also some messages of the same date. However, I can't explain why Christoph's code is so sensitive to the difference. update 30mar2011 14. rnormal(), the Gaussian random-number generation function in both Stata and Mata, now produces different, better values. Prior results are reproduced under version control. rnormal() produced sequences that were insufficiently random for certain applications. After setting the seed, the sign of the first random number drawn was correlated with the sign of the first random number that would be drawn after setting a different seed; the sign of the second random number drawn was correlated with the sign of the second random number that would be drawn; and so on. Thus the sequence produced by rnormal() after set seed was not statistically independent from the sequence produced after another set seed command. This lack of independence made no difference in the statistical quality of results when the seed was set only once, because the lack of independence did not arise. Setting the seed once is typical in many cases, including the running of simulations. The correlation is of statistical concern when the seed is set more than once in the same problem. Only the rnormal() function had this problem. None of Stata's other random-number functions, such as runiform(), rbeta(), etc., had this problem. The problem is fixed, with the result that random-number sequences produced by rnormal() are now different. If you need to re-create previously produced results, use version control and specify a version prior to 11.2 when setting the random number seed with set seed. 15. Help for set seed now includes useful advice on how to set the seed and explains the difference between a random-number generator seed and its state as recorded in c(seed). 16. The way version control is handled for random-number generators has changed. Version control is now specified at the time command set seed is issued; the version in effect at the time the random-number generator (for example, rnormal()) is used is now irrelevant. The situation was previously the other way around. Under the new scheme, typing . set seed 123456789 . any_command causes any_command to use the new, version 11.2 rnormal() function even if any_command is an ado-file itself containing explicit versioning for an earlier release. Thus existing ado-files need not be updated to benefit from the updated rnormal() function. Similarly, if you wish to run any_command using the prior version of rnormal(), you may type . version 11.1: set seed 123456789 . any_command Even years from now, any_command will still use the 11.1 version of rnormal(), and it will do that even if any_command was written for a later release of Stata. 17. Programmers do not need to update their previously written ado-files because of the change in function rnormal(), with one exception. If the ado-file itself contains a set seed command, the ado-file should be updated to use the version in effect at the time the ado-file was called. To do this, early in the code, obtain the version of the caller. Later, use the caller's version when issuing command set seed: program xxx version ... syntax ... ... local callersversion = _caller() ... version `callersversion': set seed ... ... end If set seed appears in a private subroutine of xxx, you must pass callersversion to the subroutine. If set seed appears in another program that you did not write, execute that program under the caller's version: program xxx version ... syntax ... ... local callersversion = _caller() ... version `callersversion': mi impute ..., seed(...) ... end 18. New creturn result c(version_rng) records the version number currently in effect for random-number generators. Nick n.j.cox@durham.ac.uk -----Original Message----- From: owner-statalist@hsphsun2.harvard.edu [mailto:owner-statalist@hsphsun2.harvard.edu] On Behalf Of Christoph Engel Sent: 17 August 2011 15:25 The following observation makes me suspect that there is a change from Stata 11.0 to Stata 12 that causes .ado files to behave differently. I have written a program to perform maximum likelihood estimation. On my previous notebook with Stata 11.0 the program converges much more often than on my new notebook with either Stata 12 or Stata 11.2. Writing "version 11" or "version 11.0" at the beginning of the command does not help either, probably because Stata 11.2 is called anyhow. A check revealed that, setting the same seed, Stata's rnormal() command generates different results. I therefore suspect that there has been a change in random number generators that causes the problem. Any suggestions for help would be highly appreciated. * * 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/

- Prev by Date:
**st: Regressing a specific number of observations containing values** - Next by Date:
**Re: st: The another problem about mm_root** - Previous by thread:
**st: Regressing a specific number of observations containing values** - Next by thread:
**st: Impute an average in a stacked dataset** - Index(es):