Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: RE: RE: Generating random variates

From   "Nick Cox" <[email protected]>
To   <[email protected]>
Subject   st: RE: RE: Generating random variates
Date   Fri, 23 Aug 2002 12:52:03 +0100

Roger Harbord
> I glanced at Thomas Steichen's message [...] and realised
> that although I
> thought I had the -rnd- package installed, the help file I
> see is quite
> different to the one he quotes.  I tried -findit rnd- again
> and saw that
> there are four sources for this package:
> 1) STB 41 sg 44.1 Correction to random number generators.
> 2) STB 28 sg 44   The original programs.
> 3) rnd from
> 4) rnd from
> I had originally installed -rnd- by clicking on the sg44.1
> link (1) and
> assumed that I had latest update, and that 3) and 4) were
> copies of this in
> other places.  However, I was wrong - to install the
> lastest versions of all
> the commands you need to click on 3) to get the latest
> version of most of the
> programs, then 4) if you want updates to F, t and
> chi-squared generators
> that allow non-centrality parameters.
> Am I the only one to find this a little confusing? (Try
> -findit rnd-
> yourself).
> I greatly appreciate the ease of installing user-written
> commands and updates
> in web-aware Stata, but this seems to be one case where
> it's not quite as
> simple as it might be.  Deciding whether to force
> installation replacing
> already-installed files was complicated by the fact that
> there seems to be no
> standard format for showing the date in the output produced
> by -findit-, or
> the help files - sometimes it's there, sometimes it's not.
> So it's not
> always immediately obvious whether you're about to install
> a newer version or
> an older version.
> Doubtless all of these updates have been announced on
> Statalist at the time,
> but I've only been using Stata since March (and getting the
> statalist-digest
> since April).  From statalist discussions earlier this year
> I'd got the
> impression that updates to STB/SJ programs should be
> published, no matter how
> briefly, in the STB/SJ.  Hence my belief that installing
> the latest STB/SJ
> insert was enough to ensure I had the latest versions.
> Having worked out the situation for -rnd- (I think), I
> guess I'm now asking:
> what's the best way in general to be sure you're installing
> the latest
> version of any package?

The general rules as I understand them are

1. If a package has been published in the STB or the SJ, and
revised in the STB or the SJ, then only the latest of several versions
should be downloaded. To repeat the substance of an earlier posting,
Editors of the SJ welcome notes of updates from authors of previous
publications in either the STB or the SJ. Those notes and the
updated software can then be documented by an entry in the data base
by Stata, so that they will be visible to users of an up-to-date
of Stata.

The result of -search- or -findit- will always show a publication
date. (If not, someone goofed; tell Stata Corp and they will
fix it.)

Comment: The one exception is this is when you are using a version
of Stata earlier than that required to run an update, in which case
may have the option of downloading an earlier version.  In this
circumstance it can be important to try to read about what was changed
in the update, so that you can learn about any bug fixes.

2. If a package has been made public through SSC, then only one
exists and only that is of interest. Occasionally, an older version
persists, most commonly to make a package available to users of
earlier versions of Stata, but that will be flagged as such, and
the package will bear a different name.

The result of -ssc describe foo- will always show a distribution
date (date package last changed). (If not, someone goofed;
tell Kit Baum and he will fix it.

3. If a package has been made public in some other way, then it
is difficult to generalise, because different authors have
their own ways of making stuff accessible and their own different
styles of describing packages. But in almost all cases
only one version is visible. In fact, I will guess in all
cases, and wait to be told of a counterexample.

This doesn't seem to help Roger much because his example is
I believe) is of a package which appears in three different
places, but -findit rnd- and a few mouse clicks reveal
that there are dates clearly given both on the Stata Corp
website material and on the SSC material.

The other general rules are

4. Ask the author!

5. Look for dates and the program's own version number.
It has long been common practice to include a comment containing the
version number of the program and the date the program was last
modified at the head of the program. In addition, many help
files bear dates (admittedly, sometimes hidden as a SMCL
comment, in which case -type, asis- will reveal it).

ssc type foo.ado

will let you peek at any program on SSC. I just typed

ssc type parmest.ado

and I see that there is a clear date 19 August 2002.
Although it needs more working out,


shows me a date of 6 October 2000 to underline the
fact that SSC bears the more recent version.

[email protected]

*   For searches and help try:

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