Postgres regr_slope возвращает NULL - PullRequest
Новая
       11

Postgres regr_slope возвращает NULL

0 голосов
/ 22 марта 2019

Может кто-нибудь помочь мне понять обстоятельства, при которых regr_slope возвращает NULL, если в наборе данных есть строки?Например: 

log=> select * from sb1 order by id, ts;
  id  | elapsed |       ts       
------+---------+----------------
 317e |      86 | 1552861322.627
 317e |      58 | 1552861324.747
 317e |      52 | 1552861325.722
 317e |      58 | 1552861326.647
 317e |      82 | 1552861327.609
 317e |     118 | 1552861328.514
 317e |      58 | 1552861329.336
 317e |      58 | 1552861330.317
 317e |      54 | 1552861330.935
 3441 |      68 | 1552861324.765
 3441 |      84 | 1552861326.665
 3441 |      56 | 1552861327.627
 3441 |      50 | 1552861330.952
 5fe6 |      42 | 1552993248.398
 5fe6 |      44 | 1552993255.883
 5fe6 |      44 | 1553166049.261
 c742 |      62 | 1552861322.149
 c742 |      68 | 1552861322.455
(18 rows)

log=> select id, regr_slope(elapsed, ts) as trend from sb1 group by id;
  id  |        trend         
------+----------------------
 c742 |                     
 317e |                     
 5fe6 | 5.78750952760444e-06
 3441 |                     
(4 rows)

Интересно, что один и тот же набор данных и функция возвращает разные результаты в Oracle 11.2: 

SQL> select * from sb1 order by id, ts;

ID            ELAPSED               TS
---------- ---------- ----------------
317e               86   1552861322.627
317e               58   1552861324.747
317e               52   1552861325.722
317e               58   1552861326.647
317e               82   1552861327.609
317e              118   1552861328.514
317e               58   1552861329.336
317e               58   1552861330.317
317e               54   1552861330.935
3441               68   1552861324.765
3441               84   1552861326.665
3441               56   1552861327.627
3441               50   1552861330.952
5fe6               42   1552993248.398
5fe6               44   1552993255.883
5fe6               44   1553166049.261
c742               62   1552861322.149
c742               68   1552861322.455

18 rows selected.

SQL> select id, regr_slope(elapsed, ts) from sb1 group by id;

ID         REGR_SLOPE(ELAPSED,TS)
---------- ----------------------
c742                   19.6078431
5fe6                   5.7875E-06
317e                   -1.0838511
3441                   -3.8283951

Я не знаю, означает ли это, что существует проблема с Postgres,Oracle, ни один, ни оба, хотя результаты для 5fe6 одинаковы.

Ответы [ 2 ]

2 голосов
/ 25 марта 2019

После копания в коде у меня есть ответ:

Проблема в том, что наивный подход PostgreSQL до версии 12 приводит к неоправданно большим ошибкам округления в этом случае.

Давайте рассмотрим id = 'c742':

Формула для regr_slope выглядит следующим образом:

regr_slope: = ( N & sdot; & Sigma; ( X i & sdot; Y i ) - & Sigma; X i & sdot; & Sigma; Y i ) / ( N & sdot; & Sigma; ( X i 2 ) - & Sigma; X i & sdot; & Sigma; X i )

Проблема в делителе: 

SELECT 2::float8 * (1552861322.149::float8 * 1552861322.149::float8 +
                    1552861322.455::float8 * 1552861322.455::float8) -
       (1552861322.149::float8 + 1552861322.455::float8) *
       (1552861322.149::float8 + 1552861322.455::float8);

 ?column? 
----------
    -2048 
(1 row)

Поскольку результат отрицательный, PostgreSQL возвращает нулевой результат.

Этого бы не произошло при использовании точных вычислений (numeric): 

SELECT 2 * (1552861322.149 * 1552861322.149 +
            1552861322.455 * 1552861322.455) -
       (1552861322.149 + 1552861322.455) *
       (1552861322.149 + 1552861322.455);

 ?column? 
----------
 0.093636
(1 row)

Поскольку PostgreSQL фиксирует e954a727f0c8872bf5203186ad0f5312f6183746 , все улучшается, и в PostgreSQL v12 PostgreSQL также возвращает правильный результат: 

select id, regr_slope(elapsed, ts) from sb1 group by id;

  id  |      regr_slope       
------+-----------------------
 c742 |    19.607858781290517
 317e |   -1.0838511987808963
 5fe6 | 5.787509483586743e-06
 3441 |    -3.828395463097356
(4 rows)
1 голос
/ 24 марта 2019

Оказывается, это связано с ошибкой в ​​расчете значения Sxx, вызванной большими значениями, которые у меня есть для моей оси x. Это описано здесь , если вам интересно.

Поскольку мои значения x получены из extract(epoch from tstz_col), для меня просто вычесть «базовое» значение, чтобы вычисление Sxx не переполнялось. Например: 

log=> select id, regr_slope(elapsed, ts - extract(epoch from now())) as trend from sb1 group by id;
  id  |        trend         
------+----------------------
 c742 |     19.5839996337891
 317e |    -1.08384865545836
 5fe6 | 5.78750948360273e-06
 3441 |    -3.82839498627572
(4 rows)

Результаты не совсем такие, как в Oracle, но я ищу только «тренд», поэтому в моем случае они хороши.

H.

...