The efforts of the Stata team to design and implement the new plugin
system are to be commended. I was however slightly disappointed to learn
that it is not possible to create new variables (and datasets) using the
current plugin interface. I wrote an ado program to read DBF and Epidata
files from inside Stata, but it ran painfully slow as all read
operations [file read command] were interpreted.
One workaround this is perhaps to implement 2 plugins: one reads the
file header and returns the info necessary to create new variables
within the calling ado file whereas the second plugin populates the
variables with the actual data. However, it would have been more
efficient if the plugin interface allows the creation of new variables.
Regards,
Salah Mahmud
Division of Cancer Epidemiology
Department of Oncology, McGill University
Gerald Bronfman Centre
546 Pine Avenue West
Montreal, Quebec
Canada H2W 1S6
> -----Original Message-----
> From: [email protected] [mailto:owner-
> [email protected]] On Behalf Of German Rodriguez
> Sent: Tuesday, July 01, 2003 9:58 PM
> To: [email protected]
> Subject: st: Plugins are here
>
> Plugins are here, see http://www.stata.com/support/plugins/.
>
> I believe there is an error in the documentation for accessing the
data
> from a Stata plugin written in C. (This is rather technical, but will
> save you time if you are experimenting with this new feature.) The
> function with signature
>
> ST_retcode SF_vdata(ST_int i, ST_int j, ST_double *z)
>
> is supposed to "read the ith observation of variable j in varlist and
> place this value in z", but i and j appear to be reversed: I think the
> first argument denotes the variable and the second the observation.
(BTW
> both count from one, not zero).
>
> To confirm this look at the rowsum.c example in the documentation,
which
> sums variables across rows. The sample code loops over observations
> using j and over variables using k. The call to retrieve variable k
for
> observation j reads
>
> SF_vdata(k,j,&z)
>
> My own attempt to compute a mean didn't work until I reversed the
> indices. This is a bit of a shame because obs,var seems more natural,
at
> least to me.
>
> When it comes to matrices my spelunking shows that
>
> ST_retcode SF_mat_el(char *mat, ST_int i, ST_int j, ST_double *z)
>
> does indeed "take{s} the [i,j] element of Stata matrix mat and stores
it
> into z". So we have a bit of an inconsistency in the way matrices and
> the data in memory are handled in terms of rows and columns.
>
> Given that the plugin technology is so new I wonder if Stata could
> change the SF_vdata (and presumably SF_vstore) interfaces to conform
to
> the documentation and maintain consistency between datasets and
> matrices.
>
> Cheers,
> Germ�n Rodr�guez
>
>
>
> *
> * 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/
*
* 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/
