Bookmark and Share

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

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

RE: st: A bug in egen and gen?

From   Nick Cox <>
To   "''" <>
Subject   RE: st: A bug in egen and gen?
Date   Fri, 18 Feb 2011 10:28:01 +0000

Thanks for your lively contribution. I think we agree on most but not all substantive points. 

A program does what it does

I agree. What I wrote was "My point, standard in computing, is that a program does what you ask, not what you want." I'll expand my point: Stata implements the command you type on precisely its own terms. It cannot infer when you want something different from (what is implied by) what you ask. 

I don't see a difference here. We are trading in truisms. Evidently I wrote unclearly as far as you are concerned, so sorry about that, but I do agree with you. 


-egen- is an awkward compromise. It's idiosyncratic and quirky, but it's at best a practical way for users to add their own functions -- in a limited sense. That's not fully satisfactory, and I'd hope that before too long it can be phased out in favour of some way that users can add their own functions to Stata (as well as commands to Stata, and functions to Mata). 

As for bugs, I take it that you have a list of -egen- bugs, with specific examples and arguments why they are bugs, that you have submitted, or will submit, to StataCorp. 

Users' suggestions

I agree with you. Users can make suggestions about what should be added to Stata, and the company will decide. Also, if users can make proposals about what should be added, other users can make comments about the merits. That to me is part of what a discussion list allows. My comments are to be seen in that spirit. If they think I'm wrong, people should say so. Nothing could be simpler. 

The wider picture is simple too. StataCorp get many more suggestions about what should be added than they can implement. Bob Yaffee alone probably has about a hundred time series things that he wants added. So, users can be in competition with each other even on proposals that StataCorp agrees would be worthwhile additions in principle. The demographic facts of "Lots of people want X" and "A wants Y, but it appears that no-one else does" are part of what they consider. At the same time, it's not an election. Y will get in if StataCorp think it's a really good idea. 


I don't know where all the agitation comes from about this. Users can set their default numeric type to -double- if they so wish. There are evidently differing views about whether StataCorp is behind the times in not setting the default default to -double-. In several years of being to change that default, I've never felt the need or the urge. You mileage may well differ. The technical arguments are not mine. Bill Gould has recently explained at great length much of the background to precision, so any debate you have should be over what you think wrong-headed in his statements. 


Mark Nichols

When is this man not defensive about anything. When the argument
fails, he blames the attitude. What Nick wants is for this "noise" to
go away. He is wrong about that. He is also wrong about precision.
Precision is about reliability. Noise is not. He is also wrong the
floating point. It was set decades ago when 1KB was considered large.
Nick is also wrong about the standard behavior in computing. A program
does what it does, not what you ask. And he is wrong about rejecting a
suggestion made to the company. He is not the company. EGEN is a buggy
command, one of the worst in STATA. It has bad name and bad syntax and
bad precision and bad behavior of replacing missing with zeros. Badly
done. The company should replace it with a new command that makes more
sense. That is my suggestion.

*   For searches and help try:

© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index