 |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
st: Re: RE: AW: IPF troubles
<>
I know, I know, I made multiple mistakes when thinking about the posts for
this particular thread, including, but not limited to, using -findit- to
find the thing and then clicking just one of the links to install and
subsequently running -adoupdate-. I thought that would land me the latest
version of -ipf-, only to discover later that mine was outdated by 6 years.
Along this sequence of commands, I exaggerated the capabilities of one or
more of them...
My complaint was that -ipf- does not check earlier for user input, possibly
in the -syntax- statement which can catch trash early. If that is not
possible, a few lines later one could add lines to check for specific
errors. The one committed by Andrew is a very obvious one, as the help file
almost invites him to submit a -string- variable. Instead -ipf- catches this
error almost by accident.
A third prob was that I assumed all of this happened with a -varlist- in
play when really it did not. Still, is the help file correct then? It seems
from the syntax diagram that the -varlist- is mandatory which it obviously
is not - look to the -syntax- statement in ipf.ado for corroboration. Should
it not be put inside square brackets?
HTH
Martin
_______________________
----- Original Message -----
From: "Nick Cox" <[email protected]>
To: <[email protected]>
Sent: Friday, May 15, 2009 7:01 PM
Subject: st: RE: AW: IPF troubles
Martin is pointing in one wrong direction and one right direction here.
What Andrew typed is totally consistent with the syntax declared in the
early lines of -ipf- to -syntax-, i.e.
syntax [varlist (default=none)] [fweight/] , FIT(string) [
CONstr(string) CONFILE(string) CONVARS(varlist) SAVE(string) EXPect
NOLOG ACC(real 0.000001)]
That is, the option -fit()- takes a string. In Andrew's case he supplied
a character string with an expression "gender + party". That's perfectly
legal.
-syntax- does not know or care what the string _means_. (Otherwise put,
-syntax- knows nothing about semantics.)
Thus in particular note that the predictors in the model are not passed
via the -varlist-. In fact, a varlist is optional, the default is none,
and in this case none was supplied. So there is literally nothing for
-syntax- to object to as far as the varlist is concerned.
However, as pointed out earlier in the thread by several people, what
Andrew typed included names of string variables, and that's not
consistent with the expectations of -ipf-, and is caught indirectly
later in the program, as Martin correctly points out.
What the -syntax- command could do in 2000, or can do now, is not
material here.
Nick
[email protected]
Martin Weiss
-trace-ing the thing shows that -ipf- does not catch the wrong type of
variable in your -varlist- at the first possible moment, i.e. in its
-syntax- statement, presumably because -syntax- was not capable of doing
that at the time the command was last edited, i.e. in 2000.
Stata finally chokes on a -drop- statement that asks it to compare the
string variable to the numeric missing value ".", which leads to the
"type
mismatch" error. Hard to diagnose without the benefit of -trace-...
Andrew Criswell
This seems like a straight forward example. But I don't understand why
it fails. I am using version 10.1
input str6 gender str8 party wgt
gender party wgt
male democrat 55
male repub 65
female democrat 50
female repub 30
end
. ipf [fweight = wgt], fit(gender + party)
Deleting all matrices......
Expansion of the various marginal models
----------------------------------------
marginal model 1 varlist : gender
marginal model 2 varlist : party
type mismatch
r(109);
end of do-file
r(109);
*
* 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/