在PostgreSQL 9.6.3中,percentile_cont和percentile_disc都没有计算出所需的第75个百分点

时间:2017-09-11 19:36:41

标签: sql database postgresql

使用百分位函数,但我没有得到所需的输出。我会说"不正确",但这些功能可能正常工作,我只是不能正确理解它们。

这些是我正在使用的数字:

n = 32

160000
202800
240000
250000
265000
280000
285000
300000
300000
300000
300000
300000
309000
325000
350000
358625
364999.92
393750
400000
420000
425000
450000
450000
463500
475000
475000
505808
525000
550000
567300
665000
900000

我对percentile_cont的理解是,如果计数是偶数,它会聚合两个数字,它会将它们相加,然后除以2。我对percentile_disc的理解是,如果计数是偶数,它只会选择最小的数字。

这是我对使用第50个(中位数)作为例子计算百分位数的理解:

如果数字(n)是奇数,则选择中间的数字;如果数字是偶数,则平均中间的两个数字。所以在这种情况下,有32个数字,所以中位数= (358625 + 364999.92) / 2 = 361812.46percentile_cont返回正确的值,因为它平均了两个值; percentile_disc返回错误的值,因为它选择了两者中最低的值。

关于其他百分位数,例如第10个,我的理解是你通过获得索引的数字(n)的百分数倍数:.10 * 32 = 3.2 index在这种情况下。然后你应该向上舍入到最接近的整数,这就是你的百分位值。如果索引是整数,那么您可以将索引中的数字与其后面的数字进行平均。

在这种情况下,percentile_cont是错误的,因为它会返回251500,即使是我可以到达的数字也是如此。我能得到的最接近的是24000, 250000, 265000平均值251666.67percentile_disc会返回250000的正确结果。

但真正的踢球者是这个:第75位。根据我的计算,它应该返回469250index = (32*.75) = 24,该索引应为(463500 + 475000) = 469250percentile_disc返回463500; percentile_cont466375返回SELECT itemcode, COUNT(itemcode) AS n, PERCENTILE_DIST(0.10) WITHIN GROUP (ORDER BY price) AS 10th, PERCENTILE_DIST(0.25) WITHIN GROUP (ORDER BY price) AS 25th, PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY price) AS median, AVG(price) AS mean, PERCENTILE_DIST(0.65) WITHIN GROUP (ORDER BY price) AS 65th, PERCENTILE_DIST(0.75) WITHIN GROUP (ORDER BY price) AS 75th, PERCENTILE_DIST(0.90) WITHIN GROUP (ORDER BY price) AS 90th FROM items WHERE itemcode = 26 AND removed IS NULL GROUP BY itemcode; ,但在我的生命中,我无法再达到该数字。

这是我的疑问:

removed

注意:NULL不是n

我需要做些什么才能使其正常运行并保持一致性?我是否需要编写一个先检查percentile_disc的函数,然后根据它是偶数还是奇数来确定哪个percentile_cont或{{1}}?

SQL小提琴:http://sqlfiddle.com/#!17/aa09c/9

1 个答案:

答案 0 :(得分:0)

将此问题发布给Reddit并获得了一些帮助。

显然,percentile_cont函数除了Excel中的percentilepercentile.inc函数外,还使用本维基百科中解释的C = 1线性插值变量进行计算:

https://en.wikipedia.org/wiki/Percentile#Second_variant.2C_.7F.27.22.60UNIQ--postMath-00000043-QINU.60.22.27.7F

显然,我一直使用的是名为Empirical Distribution with Averaging。

因此PostgreSQL的原生功能不能很好地工作,需要制作一个自定义功能,我将在完成后发布。 (我怀疑它将使用9.4之前的旧ntile方法,但仍在研究它。)

但无论如何,这就是关闭的原因。