<>
" There is a little bit of inside knowledge here, itself learnable from
. viewsource egen.ado
that a call to -egen- with a call to function -foobar- fires up
_gfoobar.ado."
I obtained the same insight from -trace-ing the execution of the code I gave
in my reply.
The semantics of a "bug" are of course debatable. What always make me
nervous is when I do not find a perceived "bug" in the archives although
inspection of the underlying code reveals it must have been around for a
considerable amount of time...
HTH
Martin
-----Ursprüngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Nick Cox
Gesendet: Donnerstag, 27. August 2009 16:57
An: [email protected]
Betreff: st: RE: AW: nummode option giving error message. why?
Looking at the code directly reveals more than looking at the
documentation or dialog.
. viewsource _gmode.ado
gets you there. There is a little bit of inside knowledge here, itself
learnable from
. viewsource egen.ado
that a call to -egen- with a call to function -foobar- fires up
_gfoobar.ado.
What Dalhia is seeing is not a bug. The program author is deliberately
trapping the call to -nummode()- with -by:-.
Why is a matter for conjecture. The option -nummode()- was introduced
when -mode()- was adopted by Stata as an official -egen- function in
Stata 7 and was not present in the original user-written function
published in STB-50 in 1999.
Thus this trap has been lurking in the code for the best part of a
decade.
I have two guesses on why the program author inserted the trap.
1. They intended to come back and insert the code necessary at a later
date, but somehow the rest of their life got in the way.
2. They guessed that the request was much more likely to be problematic
than not. If you are working with -by:- you are subdividing the data so
you would need a lot of data in every group for -nummode()- to work at
all satisfactorily.
These are just guesses. If obliged, I would go for 2.
What is certain, however, is that there is no bug. Dalhia's choice is
deliberately trapped by the code. In principle, Dalhia could program her
way out of the bag by cloning _gmode and replacing it with a function
that acts as desired.
Nick
[email protected]
Martin Weiss
The documentation for -egen- is indeed unclear on this point:
******
clear*
set obs 1000
gen x=1+int(10 /*
*/ *runiform())
gen byte dummy=_n<=`=_N/2'
bys dummy: egen mymode = /*
*/ mode(x), num(1)
******
The code leads to an error although the help file does not make the
source
of the error clear - nor does the dialog box keep one from specifying
-by-
and -nummode- simultaneously.
For -nummode(1)-, the equivalent
***
bys dummy: egen mymode = /*
*/ mode(x), min
***
works fine, so Dalhia can get what she wants...
Dalhia
I am trying to use the nummode option for 'egen mode'. Here is the exact
command:
bysort name1: egen additionalcusip1=mode( cusip), nummode(1)
The same command when used with the maxmode or minmode option works
fine,
but when I use nummode (which is what I need), stata gives me the
following
error:
option nummode() may not be combined with by
Can anyone tell me why this is happening? Is this a bug in stata or am I
doing something wrong?
*
* 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/
