[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

From |
"Nick Cox" <n.j.cox@durham.ac.uk> |

To |
<statalist@hsphsun2.harvard.edu> |

Subject |
RE: st: RE: Accessing command line parameters |

Date |
Wed, 13 Feb 2008 23:12:41 -0000 |

For the record, I have not suggested, and would not suggest, that you or anybody else be "kicked off the forum" for particular kinds of questions on Stata. That is an absurd mis-reading of my posting, but no doubt I was just not clear enough, and the fault is mine. I am just giving _advice_ -- to repeat a carefully chosen word -- that I think you have a very low probability of getting an answer from Statalist on questions like the one you just asked, and I explained in detail why I think that is so. That advice stands or falls on whether it is correct. People often overlook things that _are_ documented. I did so myself only a few days ago on a topic I have studied quite a lot, Stata's graphics. But no matter. It appears from your last paragraph that you have found an answer to your question. That's good. Nick n.j.cox@durham.ac.uk Sergiy Radyakin Thank you for your answer Nick. It was very helpful. I am just a bit puzzled, since when command line parameters became proprietary secret of Stata Corp??? Every DOS/Windows program may have command line parameters, and it is me, myself or I who is going to supply them. The only question here is whether these parameters are made accessible within Stata for .ado programmers or not? You may or may not know the answer. I don't care. I know nothing about "Moran's I", which was discussed today, but I don't feel it is correct to kick people off the forum just because they ask questions that you don't know the answer to. Leave them for someone who knows the answer. Your statement about "undocumented-ness" is at least strange. Why would I ask about the things, which are described in the manual? I can just read the manual. Anyways, in lite of my original question, you could have pointed to an article by Chinh Nguyen, StataCorp, where it is described how to tell Stata to set memory size before attempting to load the file WITH THE COMMAND LINE PARAMETERS. Too bad you haven't read it. Regards, Sergiy On 2/13/08, Nick Cox <n.j.cox@durham.ac.uk> wrote: > My guess is that whatever is not accessible via -creturn list- is in a > private place not accessible to users, or even user-programmers. I could > be very wrong, but that is my guess. > > But there is another perspective also. Your questions like this are > quite deep and often go way beyond what is documented. Very likely, only > StataCorp know the answers, or know that you are not quite asking the > right questions. What is the prior probability that they would want to > disclose details of their internals in a very public place? I sense > three possibilities, not exclusive. > > 1. You are asking for something that is a proprietary secret. > > 2. You are asking for an answer which would not make sense to you if it > were given, because you would need lots of other information to make use > of it. > > 3. StataCorp might be willing in principle to give you some information > but wary of talking about matters that are almost always done by Stata > on users' behalf. You might be asking for information that once released > could tempt yourself or other users into experimentation that might land > people in messy situations. Disclosure would not be worth the downside > of what might go wrong. > > As I say, I am guessing. But I match your question in a public place > with advice in a public place: Take these questions off the list and > talk directly to StataCorp. They might have a direct answer (including > No). They might be very interested in working with you to apply Stata in > quite novel territory, possibly after some non-disclosure agreement. > That's a better strategy than asking these questions in this forum. > > Nick > n.j.cox@durham.ac.uk > > Sergiy Radyakin > > I wonder if I can read the parameters that Stata receives when it is > launched. I want to automatically set memory (in the profile.do) to be > at least as big as necessary for the dataset that is being opened > (with a double-click in explorer/windows). > > If it is possible, where does Stata store these command line parameters? > > ************************************************************************ > ********************** > ** this is what I see when I double-click a large file in Windows: > > running C:\...\profile.do ... > > . use C:\DataDir\MyDataset.DTA > no room to add more observations > An attempt was made to increase the number of observations beyond > what is currently possible. You have the following > alternatives: > > 1. Store your variables more efficiently; see help compress. > (Think of Stata's data area as the area of a rectangle; > Stata can trade off width and length.) > > 2. Drop some variables or observations; see help drop. > > 3. Increase the amount of memory allocated to the data area > using the set memory command; see help memory. > r(901); > * * * 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/

**Follow-Ups**:**Re: st: RE: Accessing command line parameters***From:*"Austin Nichols" <austinnichols@gmail.com>

**References**:**st: Accessing command line parameters***From:*"Sergiy Radyakin" <serjradyakin@gmail.com>

**st: RE: Accessing command line parameters***From:*"Nick Cox" <n.j.cox@durham.ac.uk>

**Re: st: RE: Accessing command line parameters***From:*"Sergiy Radyakin" <serjradyakin@gmail.com>

- Prev by Date:
**Re: st: RE: Accessing command line parameters** - Next by Date:
**st: problem with generating eps** - Previous by thread:
**Re: st: RE: Accessing command line parameters** - Next by thread:
**Re: st: RE: Accessing command line parameters** - Index(es):

© Copyright 1996–2017 StataCorp LLC | Terms of use | Privacy | Contact us | What's new | Site index |