[Jesse Wursten]

So string "23.4" should be "234"? Or string(23) + string(.) + string(4) should return something different from string(23.4)?

Ah, I see your point now. I guess the issue in the end comes from the fact that Stata does not use a "special" character to indicate numeric missings, which means string can't distinguish between a "missing dot" and an "actual dot".

Perhaps a compromise would be to add a "missing" option to the official tostring command, which would turn dots to empty strings if specified. Of course the user can do this themselves, but I'd be very surprised if the cases where you want string(.) to turn into a . outnumber the cases where you just want numeric missings to become string missings? If that's actually so, I'd say it makes sense to include the functionality in the command everyone uses, rather than requiring everyone to add that snippet of code themselves?

[Nick Cox]

I don't think the proper syntax or behaviour of Stata is to be decided by straw polls of anyone happening to notice a thread on Statalist. That's just not how Stata changes. Shucks, even R doesn't change that way. The way you change Stata is by writing to StataCorp and telling them that you think you have found a bug or a misfeature and suggesting a change and being so convincing that they agree.

tostring is just an elaborate wrapper for string(). Accordingly both map system missing to the string ".".

You have not addressed the example I gave in #29. string() rests on character-to-character conversion and its logic should not depend on what strings mean.

But if any users want "" not "." in converting numbers to string then they can get that deliberately with e.g.

cond(string(whatever) == ".", "", string(whatever))

and/or by cloning tostring to act as they wish. If people wanted this previously it's a small mystery why some user-programmer has not apparently done this before. Feel free to do that.

An additional option to tostring forcing isolated "." to be "" would break nothing. (EDIT: Jesse Wursten was independently suggesting that while I was writing.)

[Kazi Bacsi]

Indeed, Jesse's idea is quite good!

[Clyde Schechter]

It was said earlier, in essence, that the information in the help files is rather cursory and that finding the appropriate manual documentation requires either scanning hundreds of pages or doing a google search. The former is a matter or taste, but the latter is flat-out untrue. -help command- is typically the first stop on the road for help. If what you find there is not sufficient for your purposes, you can always go directly to the corresponding manual section for any official Stata command. The first section of Stata official help files is the "Title" section, and there you will find the name of the command in blue. The blue color indicates that it is a clickable link. If you click on that link, the manual opens up directly on the section for that command. It's as simple as that.

[Kazi Bacsi]

I perfectly know how to use the basic help command and the more detailed PDFs. My problem with the PDF is, apart from being slow, I would be seriously surprised if it never ever happened to you (because these are several hunded pager PDFs) that the slightest mouse scroll or click on the scroll bar took you some 50 pages away of the spot you were searching. A website is far easier, quicker and more convenient to handle. Just take a look at these:

SAS

Matlab

[Clyde Schechter]

My problem with the PDF is, apart from being slow, I would be seriously surprised if it never ever happened to you (because these are several hunded pager PDFs) that the slightest mouse scroll or click on the scroll bar took you some 50 pages away of the spot you were searching.

Well, I don't know why you find the PDF slow. It opens instantly for me. I have literally never encountered any delays in getting to the installed documentation, and I've been using Stata since (long before) they switched over to installed PDF documentation. If you do, you might need to try re-installing, or, if that doesn't solve the problem, consult with Stata's technical support about it.

Yes, I have occasionally made mousing errors that take me far from my original, intended place. But I find that, if anything, there are fewer such booby-traps in the Stata documentation than there are on most websites I visit. For my work habits, at least, I greatly prefer the PDF documentation to HTML.

Look, ultimately every statistics package has its pros and cons, and each is better suited to some people's work styles than it is to others'. I personally used SAS for a few years back in the 80's and I just hated it. You couldn't pay me enough to go back to using it. But some of my colleagues work very happily and productively with it and those people tend not to like Stata. That's fine. Different strokes for different folks, as they say.

We're all entitled to our opinions about these things. But a majority vote does not strike me as a practical way to work things out. After all, the developers themselves have a much more in-depth understanding of what is feasible and can be made compatible with both the existing code that has been written for Stata over the years, and what is compatible with the overall architecture of Stata than any users do.

Moreover, some of the things you're getting exercised over in this thread you can easily solve for yourself: just write some short wrapper programs that modify the behavior of the commands you don't like. One of the best things about Stata, in my opinion, is how easy it is to do just that. If you like Jesse Wursten's idea in #33, then just do it! Write a new -tostring- command with a -missing- option. Publish it on SSC, so others can use it, too. This is a very easily solved problem.

Forums like this are a great way for people to voice their opinions about issues like this. There is even a Wishlist for Stata 15 thread specifically for suggestions about changes to Stata and discussion of those suggestions. (And, I think, most of this thread beyond the first few posts really belongs there.) But if the bottom line for you is that you just don't like Stata's overall approach to statistical computing, then I think the place to take that up is with whoever is forcing you to use it.

[Kazi Bacsi]

Indeed, all softwares have its pros and cons. In SAS the macro language is extremely powerful, charts are also cool, but error handling and formats can cause nightmares. Unfortunately these are not always carefully considered. I taught SPSS at a university, because there was a good relationship between them and the professors, and the students didn't like coding. Most of the banks use SAS, but I suppose it's the result of their marketing (indeed ODBC connections and data servers are quite cool). Stata is preferred by econ guys, again a convention. At my previous place we had all three, now I have only Stata, and it's not me to decide. So many times it's just hard to switch, or people don't like to learn something new.

If you have in mind some nice tutorial how to do a wrapper program, I'd be more than happy to read it!

[Clyde Schechter]

Christopher Baum's recent book An Introduction to Stata Programming would cover this and much more. And the book's examples are, to a great extent, drawn from economics and finance.

[daniel klein]

Also type

help program

and read [U] 18 Programming Stata as well as the other entries referred to. One of the great things about Stata is that you do not need to buy books to learn how to do things (although I highly recommend Kit's work mentioned by Cyde. It is excellent). Also note that lots of Stata's programs are open source. Type

viewsource tostring.ado

to view the source code of tostring. Looking into programs written by others in Stata can help learning how to do it.

It can obviously be a frustrating experience to use a software that you did not chose, but my guess is, if you give Stata a chance and some time, there is a good chance you will not want to go back after one year or so. At least this is what you hear from many Stata users who have started with SPSS or SAS.

Best
Daniel

[Kazi Bacsi]

I've been using Stata for something like 2 years now. Obviously it has its pros and cons, but it's fine. SAS has library assignment, so you don't need to do use and clear all all the time, and SQL integration makes working with multiple tables quite easy. But as I know for example Stata costs far less, and to mention a serious nightmare in SAS related to the formats, is that it's not that easy to import an Excel spreadsheet with long strings without being truncated, moreover it's quite hard sometimes to detect. On the contrary, Stata adjusts formats on the run to accomodate longer strings and shows real changes, which is again quite nice feature for detecting bugs. Another thing is that I thought earlier that SAS was quicker, because it didn't load everything to memory, but my practice seems to contradict this (and a cheap PC has nowadays 2-4GB of memory as well). Would be nice to do a comparison of speed once. Thanks for viewsource tip!

Meanwhile I've found this (bit outdated, but gets the main points):
http://www.ats.ucla.edu/stat/mult_pk...e_packages.htm

[Jesse Wursten]

I've been using Stata for something like 2 years now. Obviously it has its pros and cons, but it's fine. SAS has library assignment, so you don't need to do use and clear all all the time, and SQL integration makes working with multiple tables quite easy. But as I know for example Stata costs far less, and to mention a serious nightmare in SAS related to the formats, is that it's not that easy to import an Excel spreadsheet with long strings without being truncated, moreover it's quite hard sometimes to detect. On the contrary, Stata adjusts formats on the run to accomodate longer strings and shows real changes, which is again quite nice feature for detecting bugs. Another thing is that I thought earlier that SAS was quicker, because it didn't load everything to memory, but my practice seems to contradict this (and a cheap PC has nowadays 2-4GB of memory as well). Would be nice to do a comparison of speed once. Thanks for viewsource tip!

Just as an aside, Stata also supports SQL, see help odbc. I use it all the time (though admittedly only to load data from an SQL source, I don't know how convenient traffic in the other direction is.

[Kazi Bacsi]

Nice! But am I mistaken that you need to set up an ODBC server for this? Or is there a way to somehow emulate one to work with local files?

[Jesse Wursten]

Nice! But am I mistaken that you need to set up an ODBC server for this? Or is there a way to somehow emulate one to work with local files?

I have no idea. I suppose it might be possible to setup a local server and use that, though in that case I feel just using Stata's merge and append commands appropriately (the keep/assert/keepusing options are very useful) is going to be 10x simpler?