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