[wbuchanan]

Ingrid Qiu Again. Stata has never officially adopted or created a Python plugin. As I mentioned previously, the integration with Python is the work of James Fiedler. More importantly, is that this is simply a language interface, so it makes it possible to use Python in Stata, but does not require it. Official Stata has Java and C APIs that user programmers are able to use to access the internals of Stata. R also includes its header files as part of the distribution so users/developers can link to their libraries. SAS also includes support for integrating Java (http://support.sas.com/resources/thi.../v93/jres.html), as do Matlab (http://www.mathworks.com/help/matlab...in-matlab.html), SPSS (ftp://public.dhe.ibm.com/software/an...Statistics.pdf), Mathematica (https://reference.wolfram.com/langua...Interface.html), and likely several others. So, yes. It is really natural for statistical software to include APIs for other languages. Embedded languages, however, are slightly different. In that case, you would be better off thinking about things in the context of TeX vs LaTeX; TeX being the Mata analog and LaTeX being the Stata analog. LaTeX is simply an abstraction of the TeX language that allows the end user to not enter many lower-level commands, but it still is sitting on top of TeX at the end of the day.

With regards to your reference, you should not be coding a loop over 300 distinct regression models in your program. That likely has effectively made the program applicable to only a single context. If your programs focus on flexibility and extensibility, then you can allow the end user to to loop through the command how ever many times they would like. Additionally, you need to consider memory consumption/allocation issues when doing something like that. The script would likely cause many computers to start swapping if the user was working with a sizable data set without abundant memory resources available. More importantly, there is already a fairly easy way to call Stata commands from within Mata (http://www.stata.com/manuals14/m-5stata.pdf#m-5stata()) and calling Mata commands from Stata just requires you to prefix the command with "mata:". I'm a bit confused about why this isn't user-friendly enough for you. What improvements would you suggest to the API?

[Daniel Bela]

Hi all,

in a recent discussion on this thread, Dirk Enzmann asked if anyone knows about a possibility to use alternate PDF viewers (as opposed to the officially recommended Adobe Reader) in conjunction with Stata's PDF documentation (and, especially, the links from the inline help files to the PDF documentation).

The result seems to be: It is only possible in Stata for Unix/Linux. The script stata_pdf in Stata's Unix/Linux installation directory documents the parameters used to call the PDF viewer, and allows modifying them. Thus, it is possible to change the targeted viewer application executable, as well as the parameters passed to this application for letting it jump directly to a page or section on the PDF files.

The same command line parameters are probably used in Stata for Windows and Stata for Mac as well, but they seem to be built-in calls in the Stata executables itself, and not a separate script. Thus, we as users are not able to use the merits of cross-linked PDF documentation in those systems, unless (a) we use Adobe Reader or Adobe Acrobat [which some of as do not want or are not able to, possibly due to company restrictions] or (b) use an alternate PDF viewer that understands the exact same command line arguments as (a) [which is the case for Foxit Reader (see page 195), but not for SumatraPDF, for instance].

So eventually, my wish for Stata 15 is: Create some kind of configuration mechanism for Stata for Mac and Stata for Windows that is comparable to the stata_pdf script in Stata for Linux, enabling us as users to choose alternate PDF viewers.

Regards
Bela

[Christophe Kolodziejczyk]

I have a wish. A Mata function similar to the Stata cond() function and which works with matrices. Actually the userwritten package moremata (written by Benn Jann) has such a function, but it is slow. I know that you can write something like

y = (cond):*(expression if cond true) +  (!cond):*(expression if cond not true)

But you have to evaluate both expressions and it will return missing if the false expression returns missing, which is not necessarily desirable. So a built-in mata function cond() would be something great to have (IMHO).

[Niels Henrik Bruun]

Sometimes mata stata functions have an underscore equivalent eg st_addvar() and _st_addvar() where the underscore version returns the error code number, but the code continues.
Regrettably sometimes there is another functionality attached to the underscore version eg st_macroexpand() and _st_macroexpand().

It would be nice to have this functionality standardized to behave like st_addvar() such that the underscore version is an exact copy wrt functionality and arguments, but it returns one value when the code go well. And returns something else when the code go wrong.

Or better still to have some try-except functionality added to mata.

[Sergiy Radyakin]

Christophe Kolodziejczyk why do you have to evaluate both expressions?

c=condition
if (c) {
  y=expression1
}
else {
  y=expression2
}

Though I agree it is not a function, so in complex formulas may not be convenient.

[Christophe Kolodziejczyk]

Sergiy Radyakin I don't want to evaluate both expressions, but it's the only way I can think of in the case where c is a vector and I want to avoid a loop. The if/else can only work if c is a scalar as far as I know. In other words I would like something you propose but in a vectorized version. There is also a conditional operator in Mata (c ? a : b), but it works only for scalars. Ben Jann has written a routine that extends this type of conditional operator to matrices, but it loops over observations and is therefore slow.

[wbuchanan]

Just ran into this issue recently. What I'd like from the behavior of the reshape command is to not destroy value label definitions but allow them to persist through the reshape (e.g., just the definition, not the assignment of the definition to the values). For example, in a larger .ado I've been putting together kdestandardize, we define multiple value labels at the start of the program. Throughout the program as certain variables are encountered it triggers the assignment of the value labels to different variables. In some of the more recent work that I've been doing on it, I need to reshape the data prior to value labels being assigned to some of the variables. After the reshaping occurs, those value label definitions are gone and cannot be assigned to any variables. So, if there is a way to not destroy the value label definitions that would help us to avoid copying/pasting the same code multiple times.

[Sergio Correia]

if there is a way to not destroy the value label definitions that would help us to avoid copying/pasting the same code multiple times.

A workaround until -reshape- gets an update would be to use the vl mata functions to back up the value labels to Mata and then add it back after the reshape. See "help mf_st_vlexists" for a list of those functions.

[wbuchanan]

Sergio Correia hadn't thought about that. Definitely seems to be a reasonable work around as well.

[Niels Henrik Bruun]

Another thing for the wishlist is project in the do editor.
If I add an existing folder eg named data to a project then I would like the project to be dynamically updated when I later saves a data file in that folder.
If I want to avoid dynamics I can add a group instead.

[Clyde Schechter]

My wish is similar to Niels' above, but slightly different. I do sometimes mingle in the same folder files that are part of the project and others that are not. (The latter may be "works in progress" or files that run some analysis that is of secondary importance.) In any case, I would like to have a "button" located next to the save icon that implements "save and add to current project" when the doeditor is running with a project open.

[wbuchanan]

Not sure how easy/possible this would be, but either a performance boost for the graphs (e.g., drawing the graphs a bit faster), parallelizing the graph creation process when using the by option, and/or parallelizing for loops for use with graphs more efficiently would be awesome. I routinely have to generate tons of graphs for individual schools and it'd be nice if I could get the task done a bit faster. Using the by option seems to be a big performance killer, but also makes the graphs more efficient visually. The last time I did something like this my machine was running for about 6-8 hours to create graphs for about 60 schools that included multiple by graphs. The end users all loved the results, but it tied up my machine for quite a bit of time (using Stata14 MP8).

Another performance bottleneck I ran into involved the destring command. Thanks in part to poor data management by another agency I had to read all the Excel files as all string data to append the files and then destring variables individually due to different combinations of strings appearing in what should have been numeric data across the files.