Nick Cox wrote:
Anyone watching: when we say -function-,
we really do mean -function- in Stata's strict
sense. A function is not a command, but something
like -log()- or -substr()-.
In principle, this is a gap. In practice,
what are you missing?
In principle, what is nice about functions
includes the way in which you can combine them,
especially but not only in what you feed to
-generate- and -replace-. Stuff like
exp(mean + sd * invnorm(uniform()))
or
real(substr(string(floor(<number>)),-2,2)
can be powerful, concise and even moderately
readable. But apart from that, I assert that
what you want can usually be done otherwise,
by a combination of existing functions, -egen-
functions, or commands. Or if that's not true
you would really rather than StataCorp did it,
because the function should be coded extremely
carefully in C.
In terms of evidence for this assertion:
scan the list of
-egen- functions, official and user-written,
to see what really deserves to be promoted to
a Stata function.
Or here's a challenge: if
your statement is true, you should be able
to name a few functions that are missing from
Stata.
In my Stata programming, I can think of only
one program I've written that really was an
awkward substitute for a function, i0kappa.ado
on SSC. And next time round it will be
rewritten in Mata anyway.
--------------------------------------------------------------------------------
Nick,
A lot can be accomplished with the combination of existing functions and
commands, but I see the inability for Stata to allow user-written functions
as a significant limitation to its extensibility. I'm growing more familiar
and comfortable with Mata, but I still will want to do most if not all of
the data management grunt work as well as all of the modeling in Stata. It
would be more than just nice to have Stata recognize functions that I write
in Mata as functions. You mention the advantages for -generate-
and -replace-, but there are situations where user-written routines would be
infinitely more natural if they could be used in Stata as functions:
1. Anything that acts on Stata matrixes should be able to be written for use
in Stata as a function, for example, -matrix define A = myfunction(A)-.
Likewise, if the command makes sense placed in Stata matrixes, as
in -matrix define A = (myfunction(A[1,1]), yourfunction(B[1,2]))-,
espcially in looping over matrix indexes. A lot of this kind of work would
be done entirely in Mata for users comfortable with that proposition, but
many users of such user-written routines will stick with Stata.
2. Anything calculating a scalar or matrix solely for further processing
should be a function; commands like -bisect- or -ridder- come to mind. (By
the way, all these do even now is just display--you cannot even get the
solution for workup.)
3. Anything returning a probability or quantile from a distribution should
be a function. If a user writes functions in Mata for, say, the Studentized
range, Studentized maximum modulus or Dunnett's t, he or she will still
have to return the results in return scalars in order to make use of them in
Stata. These ought to be as natural to use inside Stata
as -normal()-, -invnchi2()- and -Ftail()- are. One of the strengths of
Stata is consistency in its syntax--this deviates from that principle. This
would apply to the Hilbe/Linde-Zwirble -rnd- suite, too, by analogy
to -generate z = invnormal(uniform())-.
4. Anything implementing a mathematical function should be useable in Stata
as a function. You began to address your own challenge by
mentioning -i0kappa-. Even when you do rewrite -i0kappa- in Mata, Stata
still won't have -i0kappa- available for use as a function any more than it
does now. Perhaps users of -i0kappa- will likely to be using it in Mata,
anyway, but there are liable to be other user-written arithmetic functions
that would find greater use among those who aren't going to be venturing
beyond Stata.
5. Anything else that you need returned in double-precision. Now, if a user
takes the time to assure precision by bounding the error in a numerical
integration, for example, the integral still gets returned from Mata to
Stata in a single-precision return scalar.
In short, just about anything that you wouldn't write in Mata as -void
function myfunction() printf("Have a nice day\n");- you should be able be
make useable in Stata as a function.
More directly to your challenge, there are functions that are missing from
Stata, e.g., manipulation of long strings, that could be directly fulfilled
by functions written in Mata if it weren't for the inability to use Mata
functions in Stata as functions. And there are other functions (and data
types) that are just plain missing: try translating the Mersenne twister
into Mata, for example. The latter sort we'll have to bite the bullet and
compile as plug-ins if we desperately need them now, but it would be better
to have Stata and Mata more compatibly married, at least for those
Mata-writable functions that you're liable to make use of in data
management, modeling and "reporting" that's best done in Stata.
Joseph Coveney
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
