# What is the "notch" in psxy -E+n?

Is it supposed to that elegant waist that box-and-wiskers sometimes show?
But it doesn’t seem to be working

``````julia> y = randn(200);

julia> GMT.boxplot(y, show=1, Vd=1)
[1.0 q50 q0 q25 q75 q100 200] = [1.0 -0.1217927001669226 -2.8534220494920612 -0.7272625744166817 0.48158392887355367 2.160107070453511 200.0]
psxy  -R0.9/1.1/-3.0534220494920614/2.360107070453511 -JX14c/9.5c -Baf -BWSen -EY+n -P -K > C:\TEMP\GMTjl_tmp.ps
``````

The notch is supposed to indicate the uncertainty in the median, I read. I assume it worked at least when implemented.

Yeap I read that too, but what is the uncertainty in the median? And what is the relation to the number of points in the dataset?

So back in the day when I researched this there was the uncertainty in the median one can derive from the sample size n (which is that extra column). This was done back in GMT 4 so I cannot recall what the source was, but googling now it says the notch half-length is

1.57 * IQR / sqrt(n)

while it looks like the GMT code has

1.7 * ((1.25 * IQR) / (1.35 * n));

which must be the original source I used. But this simplifies to

1.57 * IQR / n);

IQR is inter-quartile range. I cannot see we take the sort of n anywhere so that seems to be a bug. Of course, we have no tests using +n which is good and bad. Maybe if you can find an example we can add a test, possibly adding a sort to lines 243 and 286 in psxy.c

So the “notch” is the “waist”?
But there is nothing to sort because `-EY` already requires the data to be provided as quartiles. My julia example accepts the raw data and computes them.

sorry, mean sort (square root, not sort auto correct).

I changed those lines to

``````s = 1.57 * (xx[2] - xx[1]) / sqrt(hinge[4]);
``````

and run one of lines in `boxwhisk.sh` test

``````echo 5 5 2 3 6 9 100 | gmt psxy -R0/10/0/10 -JX4i -P -Bafg5 -Xc -EY+p1p+w10p+n -Sp -Glightblue -W0.5p > lixo.ps
``````

and made no difference. Still no (whatever that is) `notch`.

OK, I will see if I have time after dinner. Life is hectic up north these days. Can you please make a PR for that change since it is clearly a bug regardless of further work.

OK, later. But you do confirm my expression is correct (because I’m not sure what those `xx` and `hinge` vars are).

Yep, the ??[2] - ??[1] is the IQR. Please do it for both the x and y whisker function