[Alex Mitrani]

I found this thread very helpful, thanks to all. I was on the verge of reporting a bug because nlogit was inexplicably dropping a large number of records without any warning. I summarized my data to check that there were no missing values and noticed that one of my id variables had some rather large values. It then ocurred to me that maybe Stata was internally producing an overflow with some operation on that variable, which would internally produce missing values and result in records being dropped. I replaced the long id variable with a simple sequential id and re-ran the code. This time it did not drop any data so I conclude that the above issue was indeed what was causing the problem.

This behaviour of Stata is not helpful - ideally it would warn the user if a Stata command (not user-written code) internally produces missing values that result in data being dropped. Could it be considered a bug? I'm not sure.

[Nick Cox]

Alex Mitrani I am glad you found this thread helpful. (I still don't understand the stance of the person who started it!) Very many bug reports here are bugs in a user's own code or misunderstanding about what code does and can be quickly resolved. On an international list people working in different time zones can be helpful in getting replies more quickly.

Otherwise the advice remains that already given. nlogit is an official command based on nested ado calls and no doubt more. Your guess at what was wrong seems to have been good, but perhaps StataCorp can help by working on their code. Unless the problem is easily reproduced with a small data example. it is likely that getting in touch with StataCorp technical services is the best way for StataCorp to become aware of this.

[Andrew Musau]

The one thing that I will point out, which is taken for granted in the previous discussions, is that you need a genuine Stata license to have your concerns processed by StataCorp. Otherwise, like others who have posted in this thread, I am puzzled by the OP's assertion that sending a bug report to [email protected] is not practical.

[Alex Mitrani]

I have some sympathy for the view that it is not practical if one is working under a tight deadline. I have tended to avoid reporting things as bugs for that reason myself, despite having a licence. On contacting technical support there is a list of things to consider and information to supply and it sometimes seems quicker to find a workaround. However, the list of things to consider is helpful and may help the user to solve their own problem. It was when I started considering submitting a bug report, and started thinking through the questions I would be asked, that I figured out what was causing the issue I was experiencing. That said, having slept on it I think it can be considered a bug and I will submit a bug report when I have time.