Bandwidth in kernel density estimator

[glu]

I can't reproduce results of kernel density estimations by EViews5-7, computing bandwith according the Formula (13.2) in EViews Users Guides (I, p.469 for EV6, or p.501 for EV7). My value of the bandwith does not coincide with that yielded by EViews under all ways of computing the 0.25 and 0.75 quantiles to obtain IQR. Maybe the matter is that I take k=1 in the formula (I use the nornal kernel) while it is not true? (The User Guides do not provide values of 'k.') Or is there a different reason for this?
Besides, I can see that EViews6 and 7 compute the left-hand and right hand bounds of densities in a differnet way than EViews5, providing a smaller range of densities. Could somebody explain the way the EViews computes the ends of kernel density estimates?

[EViews Glenn]

I really can't answer why your calculations don't match since I'm not certain what you are doing. For what it's worth, we appear to follow convention in the literature using the non-df corrected s and the ordinary definition of the quartiles. Perhaps the df correction is the issue.

The method of computing the ends of the kernel densities is rather complex. As you know, for kernels with support over the entire line, there is no right answer as to where to begin the graphs. We use a complex rule of thumb which uses the chosen bandwidth, properties of the specified kernel, and the min and max of the data values. Basically, we try to get beyond the min and max, but too far beyond...

[glu]

Glenn, I could send my program and the data in order that you can see the way of my computation of the bandwidth. In my case, the IQR works, and not the standard deviation.

[glu]

I use the following way of computing the bandwidth:

!N=@obs({%1}) 'the number of observations
'{%1} is the source series
!IQR=(@quantile({%1}, 0.75,2)-@quantile({%1}, 0.25,2))/1.34
!s=@stdevp({%1})
if !s<!IQR then 'Silverman bandwidth (!h)
!h=0.9*!s/!N^0.2
else
!h=0.9*!IQR/!N^0.2
endif

[EViews Glenn]

I haven't checked the entire computation carefully (it looks okay at a glance), but I did notice that you didn't have the "o" option in the @quantile.

[glu]

@quantile({%1}, 0.75,2) is equivant to @quantile({%1}, 0.75,"o"); the former is a heritage of EViews5.
I'have just now checked that both specifications yield the same result in EViews6.

[EViews Glenn]

I hadn't remembered the old syntax for the @quantile. Thanks...

I just checked your computed kernel for the ER20001 series (0.26136) against the one used in the kernel graph for the same series (0.2614). They appear to be the same. This computation uses the IQR.

If I do the same check for WDA2001, you get h=0.038353. The graph reports 0.03835 which again matches. From the output of your program it appears that this calculation uses the @STDEVP.

So I'm not clear as to what you believe doesn't match.

Note that these calculations are for the Normal kernel.

[glu]

Sorry, I've attached a wrong .wf1 file.
Here, I attach a file where my and EViews6's esimates of the bandwidth does not coincide, using IQR.
Series PRICE2001 in this file is the same as ALL2001 in the previous workfile.

[EViews Glenn]

Thanks for the example, that helps a lot...

It appears to be a bug in the graph computation. For historical reasons, the graph routine goes through a different set of code than the base @quantile function. As you have found, in some cases, the interpolation of values in the quantile calculation is performed incorrectly in the graph code.

I'll put the fix through for inclusion in the EViews 7 source. I do note, however, that you are using both EViews 6 and 7. I doubt that this bugfix will be pushed back to the earlier code base.

Thanksagain for your time and effort in pointing this one out. The example helped greatly. Sorry for the inconvenience.

[glu]

Thank you, it's a relief. I'm writing a program for estimating conditional kernel probality density; and I'd like it to work as close as possible to the EViews manner. That is why I have tried at first to reproduce this manner for a univariate density. So, it does not matter for me that the bug will not be corrected in the earlier versions.
If it will not too burden you, could you please provide me with the algorithm EViews uses to compute the ends of kernel densities for the case of Normal kernel (in some programming language)?

[EViews Glenn]

Send me email and we'll discuss this.