Does anyone know if the spseg command was ever implemented in Stata? I was reading Reardon and O’Sullivan (2004) paper and came across a PowerPoint lecture where Maurizio Pisati describes the spseg command in Stata. I tried to implement it, but it doesn't seem to exist in Stata and there isn't any documentation on it. I know that R has a similarly named package, but was wondering if the package was ever implemented in Stata. I’d prefer to use the Stata package, if that’s available.
According to Maurizio Pisati, it was never implemented.
Related
Is there a simple way to count how many functions, methods and/or classes there are in a library? And how many are documented? Maybe through Doxygen output?
When I try to Google a solution all I get is algorithms to count things... :)
There is a tool named Coverxygen which requires XML output from Doxygen.
Install it by:
pip install coverxygen
Bonus:
If you use Sphinx and Doxygen (and Breathe) to generate documentations, you can use DocsCov to make a badge showing documentation coverage to show on your README.
As Xin Huang pointed out in a comment above, there is a useful tool called doxy-coverage.py at https://github.com/alobbs/doxy-coverage. It prints, for each file documented with Doxygen, it prints how many entities it has (namespaces, free functions, classes, member functions, enums, #defines, etc) and how many of those are documented. It lists each of the non-documented entities. At the bottom it gives a summary of the documentation coverage (percent entities that are documented). It uses the XML output of Doxygen to do so.
I replaced the line
print("%d%% API documentation coverage" %(total_per))
by
print ('%3d%% API documentation coverage (%d of %d)'%(total_per, total_yes, total_all))
To add the total number of entities and total number of documented entities in the project.
It seems possible to modify the tool to distinguish entities by type. If I ever do this, I'll post the resulting code here.
Suppose I have a database with file names and I would like add file modification dates and times to this database. Is it possible to do it in Stata in a straightforward way?
I can think of two non-straightforward ways:
1) Writing a plugin in C or Java.
2) Using dir command, capturing the output in a log file, and then importing that log file back.
But is there a less cumbersome solution?
There does not seem to be either a Stata or a Mata function that is of any help. I realize that I can easily do it in any scripting language and then import the results into Stata but I would like to know if there is a purely Stata solution (for portability reasons).
I think you can do that using the shell capabilities of Stata.
See here:
http://www.stata.com/help.cgi?shell
If I publish an .ado package for Stata, I can include .dta files among the installation files in the .pkg description file, using a line like:
f amazingdata.dta
However, it is not clear how, other than by navigating to an out-of-the-way directory for user-selected add-on packages how users can load these data. For example, is there a way to make data files for .ado files available with commands like:
. sysuse amazingdata
You have found the documentation for package files, so this seems to be a question in the first instance about whether sysuse marches with installations of user-written packages, and the short answer is an emphatic No.
sysuse is intended as a quick-and-easy way for Stata users to access datasets made available by StataCorp to support official commands. I have not tried it, but my guess is that sysuse would work with any dataset so long as that dataset was placed in the directories searched by Stata.
However, I would argue that would be very poor style. When Stata programmers publish a package centred on programs and their help files, they often make test datasets available, but the best standard is to mark such files as ancillary and let users download them to a location of their own choice using net get. As said, this is a choice.
The argument can be strengthened. It's best practice to keep StataCorp's own files and other files strictly segregated. That way, updates and upgrades, copying files to other machines, etc. all are much less likely to get confused or tangled given some clash of names. Most likely, you might install or reinstall Stata and "forget" that you had user-written stuff mixed in with StataCorp's own files and waste time trying to find it.
In any case, for sysuse to work like this, users would have to install files manually in the place(s) searched by Stata, as Stata's download commmands would not do that automatically.
As for "out-of-the-way", this is not for you to decide. Many users have very strict personal or workplace rules that each project requires quite different directories or folders, so placing files only where they can be found quite deliberately is, in their own terms, a very good idea. Otherwise put, the net get mechanism implies that users decide, carefully or not, where files are to go. Users also have the scope to manipulate their adopath should they wish to supplement Stata's rules on where it searches.
Turns out that I misunderstood the installation process, and that the functionality I desire is in Stata. I had assumed that the data files were automatically installed, but see now that they are considered ancillary, and require additional explicit installation. When this is done, the user gains access by simply typing, for example, use amazingdata. Done. Simple!
Basically, I want to be to be able to pass data between Excel cells and
my C++ program. I don't have any experience in Excel/C++ interactions and I haven't been able to find a coherent explanation or documentation on any websites. If someone could link me some references or provide one themselves it would be much appreciated. Thanks.
If this is for a Windows system, you could always use one of the available managed Excel libraries, such as OfficeWriter or Aspose.
There also might be similar libraries specifically for c++, I know we (OfficeWriter) used to make one.
Edit: Looks like there are a few out there, like LibXL and BasicExcel.
If the application will run on an end user machine with Excel installed, you can easily use the Excel interop and keep Excel hidden.
In addition to LibXL and BasicExcel mentioned by smoore, there is:
ExcelFormat Library is an improved version of the BasicExcel library and will allow you to read and write simple values. It is free.
xlslib will also read and write simple values, I have not tried it tho. It is also free.
Number Duck, is a commercial library that I have written, It supports reading and writing values, formulas and pictures. The website has examples of how to use the features.
Assume here is the data set.....
Aspect Evaluation Quarter Percentage
HOST/HOSTESS DIVERSIONS /687 Excellent Q1 40%
ROCKIN' BAR D / WAVEBANDS/ EVOLUTION Excellent Q1 50%
KNOWLEDGE OF SERVER TEAM – ROTATION Excellent Q1 60%
Trying to generate below Excel Sheet with same color and Structure, assume the above percentage will be populated in “% Within” column ......
Any way to get the excel in this required format....?I appreciate any help...
Thanks,
Sam
If you're going to do color and such, you have a few options. PROC EXPORT won't do it, of course. So instead, you need to do either Excel Tagsets, DDE, or create an unformatted sheet and use a macro from a template to copy the colors in.
Benefits/Drawbacks:
Excel Tagsets:
Benefits: Make the exact format entirely in SAS code. Have a great deal of control with a fairly simple interface. Uses the powerful PROC TEMPLATE to define styles, which allows highly portable and reusable code.
Drawbacks: Makes an .xml file that is readable by excel, not actually a .xls/.xlsx file. Does have some limitations in what it can do. Can be buggy. Probably the slowest to code of the three options, unless you are very familiar with it.
DDE:
Benefits: Once you make the template (once) in Excel, can make exactly what you want fully in SAS. Can do 100% of what Excel does.
Drawbacks: Uses somewhat outdated method, so fewer SAS programmers are familiar with it. Requires Excel to be installed on the machine, and open (you can open it as part of the DDE program). Somewhat slower to copy data in, and requires more careful checking to verify data went where it should go. Requires knowing DDE commands.
Template/copy:
Benefits: Likely fastest method in terms of set up time. Can do everything exactly like what excel does. Easy for other programmers to understand, as long as they know Excel/VBA and SAS.
Drawbacks: requires outside-of-SAS step to run copy macro (could be called from SAS via DDE or batch file, but more commonly would be done by hand). Does require some knowledge of VBA as well as SAS.
In general, I recommend trying Excel Tagsets first; if they don't work for your needs, try either of the other two options. Some good papers on Excel Tagsets for the beginner:
http://support.sas.com/resources/papers/proceedings11/170-2011.pdf
http://support.sas.com/resources/papers/proceedings12/207-2012.pdf
http://www2.sas.com/proceedings/forum2008/036-2008.pdf
I think you could create the above pretty easily using excel tagsets and proc report; follow the first paper in particular as it seems to be the most similar to what you're doing. If you run into any issues, post them as separate questions and we should be able to help you out.