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

Re: st: re: programming new function

From   Jean-Benoit Hardouin <>
Subject   Re: st: re: programming new function
Date   Sun, 17 Apr 2005 12:17:15 +0200

Ok, I understand that it is impossible to write a "real function" as these ones describes in "help function", but it is always possible to use indirect ways :

Instead to obtain a real function as
scalar x=gzap(...)

I can program the gzap command such
program define _gzap
return scalar result=...

. _gzap ...
. scalar x=r(result)

who can be used as
. egen tmp=gzap(...)
. scalar x=tmp[_N]

Thank you to Renzo and Kit for their responses, even I am desappointed to not have th possibility to program a real function.
Jean-Benoit Hardouin

Kit Baum a écrit :

Renzo replied to Jean-Benoit with

To the best of my knowledge, it is not possible to program a new function on
its own.
Of course, it is possible to modify any official command that StataCorp
writes as an ado file; but I think this "hacking" is risky and not
recommended. Of course, you could create a copy of the command (e.g. you
could make a copy of egen, call it egen2) and than modify the copy using
standard -syntax-. According to the difficulty of the command you are
modifying, this way could be quite difficult too.
Another way that might work on occasion is to write a new command

Partially right. Functions that appear in 'help functions' are those used by GENERATE, and the generate command cannot be extended by users to apply new functions. Those functions are coded in C, and are thus quite efficient. Functions that appear after the command EGEN (Extended GENerate) may be either provided by StataCorp or user-written; e.g. findit egenmore for a large library of such functions. You need NOT duplicate official egen.ado, since it is merely a wrapper for those functions. If you create a file _gzap.ado on the adopath, you will be able to use the 'zap' function with egen.

The downside of egen functions is that they are interpreted code, and if they are doing a lot of work they may be quite slow. That is presumably one of the disadvantages that Stata 9's 'mata' matrix programming language may be able to address.

Kit Baum, Boston College Economics

* For searches and help try:

Jean-Benoit Hardouin
Observatoire Régional de la Santé du Centre
BP 2439
1, rue Porte Madeleine
45032 Orléans Cedex 1
tél : 02 38 74 48 80
fax : 02 38 74 48 81
Email :

*   For searches and help try:

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