Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: access to rule-of-thumb bandwidth for local regressions


From   Nick Cox <[email protected]>
To   "[email protected]" <[email protected]>
Subject   Re: st: access to rule-of-thumb bandwidth for local regressions
Date   Tue, 18 Mar 2014 17:34:42 +0000

Generalizing this, and personalizing this, whenever I use -lpoly- or
-kdensity- I usually just fool around until I see a curve I like (or
abandon the enterprise). The curve I like will

1. be not too complicated

2. seem to make scientific sense (substitute "economic sense", or whatever)

3. be for some round number bandwidth, 50 metres, or whatever. (That's
then something I can use without embarrassment consistently for
comparisons, which is after all what are most often being sought
here.)

I wouldn't ever want to quote 48.1209 or whatever -lpoly- or
-kdensity- produces by default. It's nice that there's some
intelligence in the program to make a first choice for me, but quoting
it as if were sacred or even statistically sanctioned seems to me to
make more of it than it deserves.

Depending on the readership, seeing 48.1209 could seem like yet more
mumbo-jumbo for some readers, or raise the question of exactly how it
was produced for a quite different class of readers, who might want to
argue the toss about other ways of getting at the "best" bandwidth.

You can infer that I have the luxury of being able to think separately
about each smoothing I do. Others might have to automate smoothing
because they are doing it so often.

"Optimized", "exact" and "robust" join "major motion picture" in the
class of often claimed, more rarely achieved.

Nick
[email protected]


On 18 March 2014 14:33, László Sándor <[email protected]> wrote:
> Thanks, Nick.
>
> Indeed, I wanted to use the calculated bandwidth for other
> calculations without needlessly running -lpoly- in its entirety. But
> as often, I was hasty on this: The cost of running a full -lpoly- is
> marginal relative to calculting only the bandwidth, esp. with less
> optimized code, not to mention the speed of my own code around all
> this, let alone the value of my time coding this up.
>
> qui lpoly, nograph
>
> is the way to go, and use r(bwidth)

On Mon, Mar 17, 2014 at 3:19 PM, Nick Cox <[email protected]> wrote:

>> I probably don't understand this question as I can't see that looking
>> deep inside the code is the answer.
>>
>> If you let -lpoly- choose bandwidth, it's shown rounded on the graph
>> and accessible thereafter as r(bandwidth). Alternatively you specify
>> the bandwidth you want. I have a sense that you want something else,
>> but I don't know what it is.

On 17 March 2014 19:06, László Sándor <[email protected]> wrote:

>>> My basic question is if there is any easy access to the bandwidth
>>> generated by -lpoly-, or if there is any other command that does
>>> optimal bandwidth calculations for local means (or local linear
>>> regressions etc.). I would appreciate the flexibility of existing code
>>> instead of me mocking up a restricted use cases.
>>>
>>> I had a look at -lpoly.ado-, and I see that most of the work is done
>>> my -_lpoly_work()- in Mata. I could not verify that this command is
>>> built in, but I could not locate the source code either.
>>>
>>> Though in the Mata call by -lpoly.ado-, I am not sure I see where the
>>> bandwidth even enters the calculation.
>>>
>>> mata: _lpoly_work(`degree',`pwidth', `l', `u', ///
>>>                           `doSE', &_lpoly_`kernel'(), `savevar')
>>>

*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index