Линейная регрессия МНК - страница 4

 
220Volt:

this->points[0] это индекс, забыл уточнить.


Tсли это так, то с каких таких значение tl_sumx получается с десятью нулями (как у вас на скриншоте)? Например, сумма чисел от 0 до 86.000 равна в точности 86.000*85.999=7.395.914.000, у вас же в 4 раза больше.

Ищите ошибку здесь...

И вообще, у меня большое подозрение, что при таком количестве точек их легко можно прореживать вдвое, втрое, а то и вдесятеро. Получите расхождение в пятом-шестом знаке после запятой, зато никаких проблем с переполнением знать не будете.

 
alsu:

Tсли это так, то с каких таких значение tl_sumx получается с десятью нулями (как у вас на скриншоте)? Например, сумма чисел от 0 до 86.000 равна в точности 86.000*85.999=7.395.914.000, у вас же в 4 раза больше.

Ищите ошибку здесь...

И вообще, у меня большое подозрение, что при таком количестве точек их легко можно прореживать вдвое, втрое, а то и вдесятеро. Получите расхождение в пятом-шестом знаке после запятой, зато никаких проблем с переполнением знать не будете.


Проблема в x*х. Нужно просто как я написал сделать, то есть преобразовать индекс в double до умножения. Или хотя бы на 1.0 умножить :)



        tl_sumx2 += (tl_last_top - this->points[0] + 1) * 1.0 *
                    (tl_last_top - this->points[0] + 1);
 
Candid:
х

Проблема в x*х. Нужно просто как я написал сделать, то есть преобразовать индекс в double до умножения. Или хотя бы на 1.0 умножить :)


проблема и там, и там)) Лучший вариант - считать все в double И ограничивать размер выборки.
 
alsu:

Tсли это так, то с каких таких значение tl_sumx получается с десятью нулями (как у вас на скриншоте)? Например, сумма чисел от 0 до 86.000 равна в точности 86.000*85.999=7.395.914.000, у вас же в 4 раза больше.

Ищите ошибку здесь...

Правильней сказать: проблемы с расчетами начались с 86000 последний расчет был при около 224640 точек. Это трендовая линия, ее вершина автоматом скользит по графику пытаясь найти конец тренда.

alsu:

И вообще, у меня большое подозрение, что при таком количестве точек их легко можно прореживать вдвое, втрое, а то и вдесятеро. Получите расхождение в пятом-шестом знаке после запятой, зато никаких проблем с переполнением знать не будете.

Согласен.

 
alsu:
проблема и там, и там)) Лучший вариант - считать все в double И ограничивать размер выборки.


В первом случае накопление идёт в double tl_sumx, там переполнения нет и на реальных историях не будет, может быть только потеря точности но до этого далеко ещё.

А с остальным согласен :)

 

Candid:
Там когда х2 считается, похоже сначала перемножаются целые, а потом приведение типов идёт. Индекс нужно с самого начала в double перегонять.

Вы правы. Именно здесь переполняется инт:

tl_sumx2 += (tl_last_top - this->points[0] + 1) *
            ((tl_last_top - this->points[0] + 1));

82607 * 82607 переполняет инт (он переполняется раньше, просто пример). Сначала посчитал это маловероятным, а оно вон как ...

Наверное у меня пробелы с цифрами, трудно укладывается что 82607 * 82607 переполняет 4 млрд. (индексы у меня бесзнаковые).

 

Candid отдельное спасибо, даже мысли не было что там может переполниться.

 

Какая-то странная у нас система счета, мы привыкли что 1000*1000 = млн, но млн * млн больше чем млрд. Засада, надо быть осторожней.

 
220Volt:

Какая-то странная у нас система счета, мы привыкли что 1000*1000 = млн, но млн * млн больше чем млрд. Засада, надо быть осторожней.


Ну просто круглое число теперь 1024 а не 1000 :))
 
встречаются два программиста. Один другому говорит: "Займи 500 рублей, а лучше 512 для ровного счета"
Причина обращения: